On Wed, 2009-11-25 at 11:50 -0800, Luke Kanies wrote: > Looking at the problems resulting from us putting facts in the get > request, e.g. #2855, makes me again think this is the wrong approach.
It was kludgy at best, and I even remember warning you about that prior to the 0.25 release. > This ability only exists because, when running multiple servers > without client binding, there's a chance that the facts get sent to a > different server than the catalog is retrieved from. > > I'm thinking that it might be a better idea to solve this problem than > to hack around it. The main solution I'm thinking of is essentially > requiring some kind of shared back-end or requiring a shared cache > such as memcached. My concern here is that we don't want to cache the facts, we want to have them at disposal to several masters. The issue with caching is that you're never sure the content will be there (that's even the whole point of cache). So what happens if memcached decides to purge the facts for a given host and said host asks for a catalog? What we need is a (more) persistent shared storage for this. And the only one we have at the moment is storeconfigs/thin_storeconfigs. Granted those are performance suckers (less of course for thin_storeconfigs), so that might not be usefull for large sites (which of course needs several masters). > A shared cache with memcached should be pretty close to trivial - just > another terminus type. This obviously adds another dependency, but > only in those cases where you 1) have multiple masters, 2) don't have > client binding to an individual master, and 3) aren't using some > common back-end (one of which will be available from us with this > information by the next major release). > > Is this a reasonable approach? It's obviously not sufficient for > 0.25.2, but I think it's a better long term direction. I see several possibilities: * we bend the REST model to POST the facts and get the catalog as a result (ie one transaction like now, but posted) * we HTTP pipeline the facts posting and the catalog get in the same stream (not sure LB wouldn't split the request in piece and direct those to different upstream masters). * we ask users to use a LB with an client ip hash load balancing scheme (ie client are sent always to the same master). * we implement a master to master protocol (or a ring ala spread or using a message queue/topic). If one client asks for a catalog to master A, A contacts the other masters for the one having the freshest facts, compiles and sends back the catalog. * we don't care and ask users wanting to have multiple masters to use a shared filesystem (whatever it is) to share the yaml dumped facts. Choose your poison :-) -- Brice Figureau Follow the latest Puppet Community evolutions on www.planetpuppet.org! -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
