Any way you can share that PDF? The main page suggests it's supposed to be public anyway so I'm assuming the required login is a mistake.
When you looked at deploying your puppet modules to the clients and getting rid of the puppetmaster model, did you consider only syncing only the modules the client needs? Then you could generate manifests on the fly as the clients request them based on queries from a database. The data will stay separate from the modules and given to the clients on a "need to know" basis, maintaining the puppetmaster security model. But with the manifest compilation done on the clients, you don't have to worry about scalability issues. With only the needed modules deployed to the clients, you then can version your modules and tell the clients which versions to pull making your dev cycles much easier. We've been designing a system that does this and so far it works very well but we haven't fully implemented it yet. I still have to design the module dependency tree algorithm. We use a queue system that we built in house to trigger puppet runs which gives us great control over run scheduling and contention. For example, if our scheduler notices we have over half the grid nodes scheduled to do a puppet run at the same time, we hold off scheduling runs for the other nodes. Or if the scheduler notices a backup is still running on a node, it will cancel a scheduled run. So centralizing your scheduling and building logic controls in to it not only help with the scalability of puppet, but with the infrastructure itself. On Feb 18, 2010, at 2:44 PM, Nigel Kersten wrote: > On Thu, Feb 18, 2010 at 9:12 AM, Trevor Vaughan <tvaug...@onyxpoint.com> > wrote: >> This is true and, unfortunately, I couldn't get to the presentation either. > > I got to read a copy over the shoulder of someone here with a login. > > I thought it was pretty skimpy really, and didn't really adequately > cover the advantages of either system. > > >> >> It's pretty well known that, given any two similar systems, the one >> written in a lower level language will probably always win in terms of >> speed and resource usage and lose in terms of community extensibility. >> >> It all comes down to what you're actually looking for in the tool. >> >> Trevor >> >> On Thu, Feb 18, 2010 at 12:06 PM, Nigel Kersten <nig...@google.com> wrote: >>> On Thu, Feb 18, 2010 at 8:59 AM, R P Herrold <herr...@owlriver.com> wrote: >>>> On Thu, 18 Feb 2010, Nigel Kersten wrote: >>>> >>>>> How, if at all, do any of you do capacity planning with Puppet? >>>> >>>> somewhat orthogonal to the question, but after reading this piece: >>>> >>>> http://www.usenix.org/publications/login/2010-02/pdfs/bjorgeengen.pdf >>>> at >>>> http://www.usenix.org/publications/login/2010-02/index.html >>>> >>>> ... doing capacity planning for puppet presently may represent a 'premature >>>> optimization' >>> >>> How is knowing how many clients your current infrastructure supports a >>> premature optimization? >>> >>> Although that pdf is in 'teal', it doesn't actually appear to be >>> available without a usenix login, which I don't have. >>> >>>> >>>> The seeming speed and scaling differences between CFengine and puppet are >>>> dramatic, and one has to ask if puppet is the right tool to bet on, in its >>>> present form >>> >>> The default configurations of the two are radically different. >>> >>> There's nothing stopping you mimicking a CFengine style setup with >>> puppet. Set up an rsync server, have your clients fetch the manifests >>> and compile them locally. >>> >>> We've considered it several times for performance reasons, but I'd >>> like to avoid exposing the raw manifests to my clients, even if you >>> fake out environments by setting different rsync sources. >>> >>> >>>> >>>> -- Russ herrold >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Puppet Users" group. >>>> To post to this group, send email to puppet-us...@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> puppet-users+unsubscr...@googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/puppet-users?hl=en. >>>> >>>> >>> >>> >>> >>> -- >>> nigel >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Puppet Users" group. >>> To post to this group, send email to puppet-us...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> puppet-users+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/puppet-users?hl=en. >>> >>> >> >> >> >> -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 >> tvaug...@onyxpoint.com >> >> -- This account not approved for unencrypted proprietary information -- >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> > > > > -- > nigel > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
