+puppet-users, puppet-dev to catch the developer-y folks too. How, if at all, do any of you do capacity planning with Puppet? I''ve worked out a snippet of ruby code that will take the cached fact data from the servers, and use that to issue a bunch of catalog retrieval requests. I ended up modifying my auth.conf (such an awesomely flexible setup) to allow a given certificate to request anyone''s catalogs, which made this all a lot easier. I''m now looking at jmeter to issue the https with client certificate GET requests, and before I dive too deeply into scripting jmeter, I thought I''d see what anyone else is doing in this space. It would be awesome if we could put something into the source distribution to do this in a standard manner so we can all compare performance on different platforms and ruby stacks. This is all a lot easier with the RESTful API than it was with XMLRPC by the way. There was the puppet-test script in ext/, but as per http://projects.reductivelabs.com/issues/3183 it doesn''t appear to have been updated for 0.25.x clients. Anyone else interested in collaborating on something to provide uniform server benchmarking with pretty graphs for management? -- 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Brice Figureau
2010-Feb-18 16:04 UTC
[Puppet Users] Re: [Puppet-dev] capacity planning with puppet.
On Thu, 2010-02-18 at 07:52 -0800, Nigel Kersten wrote:> +puppet-users, puppet-dev to catch the developer-y folks too. > > > How, if at all, do any of you do capacity planning with Puppet? > > I''ve worked out a snippet of ruby code that will take the cached fact > data from the servers, and use that to issue a bunch of catalog > retrieval requests. I ended up modifying my auth.conf (such an > awesomely flexible setup)Thanks :-)> to allow a given certificate to request > anyone''s catalogs, which made this all a lot easier. > > I''m now looking at jmeter to issue the https with client certificate > GET requests, and before I dive too deeply into scripting jmeter, I > thought I''d see what anyone else is doing in this space.I''m not familiar with jmeter, but I suppose you want to measure request service time. But what would also be interesting is memory and or CPU consumption on the host. I''m not sure jmeter can gather those metrics by itself.> It would be awesome if we could put something into the source > distribution to do this in a standard manner so we can all compare > performance on different platforms and ruby stacks.That''s a really interesting idea. I''d really like to compare MRI to JRuby for Puppet deployement (or even to compare a glassfish to something else).> This is all a lot easier with the RESTful API than it was with XMLRPC > by the way. > > There was the puppet-test script in ext/, but as per > http://projects.reductivelabs.com/issues/3183 it doesn''t appear to > have been updated for 0.25.x clients.That''s too bad, it was really useful to trigger catalog compile to profile the master.> Anyone else interested in collaborating on something to provide > uniform server benchmarking with pretty graphs for management?It''s not like I''d have the time to help, but at least I can offer to discuss implementation or concepts... -- 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 Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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'' 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 -- 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Feb 18, 2010 at 8:59 AM, R P Herrold <herrold@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 formThe 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-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
This is true and, unfortunately, I couldn''t get to the presentation either. 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 <nigelk@google.com> wrote:> On Thu, Feb 18, 2010 at 8:59 AM, R P Herrold <herrold@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-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@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-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@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 tvaughan@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
R P Herrold writes: > 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'' > > 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 > > -- Russ herrold I think the only real conclusion one can draw from that article is that Ruby is slower than C. Doing capacity planning for Puppet is hardly premature; at most you have to plan to allow more resource usage for Puppet. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Feb 18, 2010 at 9:12 AM, Trevor Vaughan <tvaughan@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 <nigelk@google.com> wrote: >> On Thu, Feb 18, 2010 at 8:59 AM, R P Herrold <herrold@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-users@googlegroups.com. >>> To unsubscribe from this group, send email to >>> puppet-users+unsubscribe@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-users@googlegroups.com. >> To unsubscribe from this group, send email to puppet-users+unsubscribe@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 > tvaughan@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-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 <tvaughan@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 <nigelk@google.com> wrote: >>> On Thu, Feb 18, 2010 at 8:59 AM, R P Herrold <herrold@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-users@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> puppet-users+unsubscribe@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-users@googlegroups.com. >>> To unsubscribe from this group, send email to puppet-users+unsubscribe@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 >> tvaughan@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-users@googlegroups.com. >> To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.