This is a great summary, but I'd reorder the list a bit based on priority and value.
On Oct 6, 2010, at 4:34 PM, Markus Roberts wrote: >> 1. Make low-end scaling easier: currently when a customer's deployment >> gets too large to be handled by a single master running Webrick, they have >> to install apache/passenger or mongrel. This can be difficult to do, >> especially >> since passenger has limited package support on some OSes (notably RHEL/ >> Centos 5). It would be nice to give people a less painful way of scaling up >> beyond what Webrick is capable of handling. > > For a moment I thought you were seriously saying that a message bus > was easier to set up than mongel. :) Not mongrel, but maybe mongrel plus a pool of load balancers. :) >> 2. Make medium-to-high-end scaling easier: currently when a customer's >> deployment gets too large to be handled by a single physical machine, they >> have to set up a load balancing infrastructure to distribute HTTPS requests >> from client machines to a suite of puppet masters. It would be nice to give >> people a way of adding CPUs to the problem (essentially creating a "catalog >> compiler farm") without forcing them to add a layer of infrastructure. > > There's also the statefulness issue; distributing requests doesn't > suffice without a way to distribute the information necessary to > satisfy the requests. Thus this load balancing is not as straight > forward as it might sound. Which load balancing? The proposed one, or the standard HTTP one? >> 3. Allow customers who already have a queueing system as part of their >> infrastructure to use it to scale Puppet, so they don't have to implement a >> special Puppet-specific piece of infrastructure. > > I'm not convinced this is viable; queuing systems are presently in > something like the lovely state of anarchy that email was in the mid > 80's; the fact that someone (A touch of info missing from Markus's message.) I basically agree, but more on the side of the fact that almost no one actually has a messaging infrastructure, just like email. I expect this will come up once in a while, but it's probably not worth being a design goal. >> 4. Make Puppet handle load spikes more robustly. Currently I understand >> from Luke that there is an avalance effect once the master reaches 100% >> capacity, wherein the machine starts thrashing and actually loses >> throughput, causing further load increases. It would be nice if we could >> guarantee that Puppet didn't try to serve more simultaneous requests than >> its processors/memory could handle, so that performance would degrade more >> gracefully in times of high load. > > This is a really strong point, IMHO. This is basically the #1 point. >> 5. Allow customers to prioritize compilations for some client machines over >> others, so that mission critical updates aren't delayed. I hadn't really thought of this, but it's pretty interesting. >> 6. Allow a "push model", where changing the manifest causes catalogs to be >> recompiled, and those catalogs are then pushed out to client machines rather >> than waiting for the client machines to contact the master and request >> catalogs. I'd phrase this a bit differently - that is, yes, it's push, but it's also generally having control on the server side rather than the client, so it enables phased deployment (deploy 10% at a time, for instance), deployment limitations such as only deploying on maintenance windows, and quite a bit more. IMO, this is the #2 point, and might actually be the #1 point. > I'd also suspect there are significant gains to be had from structured > "bulk" recompilations when the cost of being smart can be amortized > over enough hosts to reap the potential benefits. (That is, with a > total cost function of c*n+k for n hosts, refactors that decrease c at > the expense of k can pay off if n is larger than our present value of > "always 1"). That would be interesting. >> 7. Allow inter-machine dependencies to be updated faster (i.e. if machine >> A's configuration depends on the stored configuration of machine B, then >> when a new catalog gets sent to machine B, push an update to machine A ASAP >> rather than waiting for it to contact the master and request a catalog). > > Yeah. Though extending the message bus to the client side as some of > these imply...hmm, The client being on the message bus isn't actually required for this point - we can kick the machine with http. >> 8. Allow the fundamental building blocks of Puppet to be decomposed more >> easily by advanced customers so that they can build in their own >> functionality, especially with respect to caching, request routing, and >> reporting. For example, a customer might decide that instead of building a >> brand new catalog in response to every catalog request, they might want to >> send a standard pre-built catalog to some clients. Customers should be able >> to do things like this (and make other extensions to puppet that we cannot >> anticipate) by putting together the building blocks of puppet in their own >> unique ways. > > I've got some concerns here in that we've presently got 3+ > not-quite-congruent decompositions in the works, but yeah, in > principle... I definitely like this, but in many ways, it just feels like #6 again. >> 9. Allow for staged rollouts--a customer may want to update a manifest on >> the master but have the change propagate to client machines in a controlled >> fashion over several days, rather than automatically deploying each machine >> whenever it happens to contact the puppet master next. Ah. I kind of consider this the same as #6, but I can see why you'd separate it. >> 10. Allow for faster file serving by allowing a client machine to request >> multiple files in parallel rather than making a separate REST request for >> every single file. > > We could do parallel request via REST just as easily, no? Kind of - a message bus is inherently asynchronous, whereas we'd have to write the asynchrony into REST. Not that hard, but not trivial, either. >> 11. Allow for fail-over: if one puppet master crashes, allow other puppet >> masters to transparently take over the work it was doing. > > And if one message bus crashes? *Theoretically*, it's not that hard to build a resilient message bus. >> E. We don't want to sacrifice error handling, and we want the system to be >> at least as robust as 0.25 and 2.6 if a puppet master crashes. > > We may actually see some improvement in error handling, in that we'll > have opportunities to detect problems in more sensical places. At the least, we should see far better auditibility, which should be awesome. -- I hate to advocate drugs, alcohol, violence, or insanity to anyone, but they've always worked for me. -- Hunter S. Thompson --------------------------------------------------------------------- Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199 -- 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.
