Hello there. Just to let you know i have just put in production mode puppet on 41 freeBSD 4.7 virtual servers (yes not real servers but "jailed ones"). I had some little problems with facter at first but i have manualy upgraded the servers that where affected by the little "facter does not read his facts" problem i had. I should have missed something in my deploiement. All was fine except some server with very slow responses. Perhaps this is why facter had some issue: notice: Finished configuration run in 1171.60 seconds notice: Finished configuration run in 1905.57 seconds notice: Finished configuration run in 1843.25 seconds notice: Finished configuration run in 2371.23 seconds The recipes i use on those box are quite simple and most of the time it takes only 10-20 seconds. i had no errors at all and all went fine, i used ruby ssh module to launch the commands and setup the beast. all is ok now so i hope my life will be better now :) Thanks Luke for the product ! -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Oct 1, 2006, at 10:40 AM, Adnet Ghislain wrote:> Hello there. > > Just to let you know i have just put in production mode puppet on > 41 freeBSD 4.7 virtual servers (yes not real servers but "jailed > ones"). I had some little problems with facter at first but i have > manualy upgraded the servers that where affected by the little > "facter does not read his facts" problem i had. I should have > missed something in my deploiement. > > All was fine except some server with very slow responses. Perhaps > this is why facter had some issue: > > notice: Finished configuration run in 1171.60 seconds > notice: Finished configuration run in 1905.57 seconds > notice: Finished configuration run in 1843.25 seconds > notice: Finished configuration run in 2371.23 seconds > > The recipes i use on those box are quite simple and most of the > time it takes only 10-20 seconds. > i had no errors at all and all went fine, i used ruby ssh module to > launch the commands and setup the beast.Ouch, those are unreasonably long runs. You aren''t seeing this most of the time, then? I''ve always been somewhat concerned that there might be performance problems for large networks or large configurations, but I haven''t heard any significant problems so far. If you continue having very slow runs, I''d like to try to figure out what''s taking so long. It could be the packaging, but I don''t remember if FreeBSD package operations tend to be slow -- if they do, then you could schedule them to happen only daily, instead of every run.> all is ok now so i hope my life will be better now :) > Thanks Luke for the product !Great, I''m glad to hear everything is working well to make your life easier. -- Luke Kanies http://madstop.com
On 02/10/06, Luke Kanies <luke@madstop.com> wrote:> On Oct 1, 2006, at 10:40 AM, Adnet Ghislain wrote: > > > Hello there. > > > > Just to let you know i have just put in production mode puppet on > > 41 freeBSD 4.7 virtual servers (yes not real servers but "jailed > > ones"). I had some little problems with facter at first but i have > > manualy upgraded the servers that where affected by the little > > "facter does not read his facts" problem i had. I should have > > missed something in my deploiement. > > > > All was fine except some server with very slow responses. Perhaps > > this is why facter had some issue: > > > > notice: Finished configuration run in 1171.60 seconds > > notice: Finished configuration run in 1905.57 seconds > > notice: Finished configuration run in 1843.25 seconds > > notice: Finished configuration run in 2371.23 seconds > > > > The recipes i use on those box are quite simple and most of the > > time it takes only 10-20 seconds. > > i had no errors at all and all went fine, i used ruby ssh module to > > launch the commands and setup the beast. > > Ouch, those are unreasonably long runs. You aren''t seeing this most > of the time, then? > > I''ve always been somewhat concerned that there might be performance > problems for large networks or large configurations, but I haven''t > heard any significant problems so far. > > If you continue having very slow runs, I''d like to try to figure out > what''s taking so long. It could be the packaging, but I don''t > remember if FreeBSD package operations tend to be slow -- if they do, > then you could schedule them to happen only daily, instead of every run. > > > all is ok now so i hope my life will be better now :) > > Thanks Luke for the product ! > > Great, I''m glad to hear everything is working well to make your life > easier. > > -- > Luke Kanies > http://madstop.comI have to ask: Is anyone running puppet in a large environment? i.e. between 100 and 1000 hosts? While I have toyed with puppet in a small lab environment, I''d hate to start seeing scaling issues once I''d deployed to only 10% of my install base. regards matthew
On Tue, Oct 03, 2006 at 10:32:53AM +1000, Matthew Flanagan wrote:> I have to ask: Is anyone running puppet in a large environment? i.e. > between 100 and 1000 hosts?I''d probably have that many running around by now. No issues with increasing size, either technical or social, thus far. - Matt
> > Ouch, those are unreasonably long runs. You aren''t seeing this most > of the time, then? > > I''ve always been somewhat concerned that there might be performance > problems for large networks or large configurations, but I haven''t > heard any significant problems so far. >is there any way to "profile" the things or to have puppet print some time information after each actions in the output of the logs so we can see which parts are taking time ? those servers are limited in ressources and ruby is quite slow to startup and memory ungry at least this is what it seems when i look at ps and top output :) regards, Ghislain. _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
2006/10/3, Matt Palmer <mpalmer@hezmatt.org>:> > On Tue, Oct 03, 2006 at 10:32:53AM +1000, Matthew Flanagan wrote: > > I have to ask: Is anyone running puppet in a large environment? i.e. > > between 100 and 1000 hosts? > > I''d probably have that many running around by now. No issues with > increasing size, either technical or social, thus far. >I''m curious about this, do they run from the same puppet server? Have you seen any type of scaling issue there? I''ve been thinking about the possibility of having kind of a tree setup, where you have a puppet "metaserver" (a puppet server able to configure child puppet servers) and then a number of puppet servers with their corresponding clients... what do you think of this? Best regards Jose _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Tue, Oct 03, 2006 at 10:32:53AM +0200, José González Gómez wrote:> 2006/10/3, Matt Palmer <mpalmer@hezmatt.org>: > > > >On Tue, Oct 03, 2006 at 10:32:53AM +1000, Matthew Flanagan wrote: > >> I have to ask: Is anyone running puppet in a large environment? i.e. > >> between 100 and 1000 hosts? > > > >I''d probably have that many running around by now. No issues with > >increasing size, either technical or social, thus far. > > I''m curious about this, do they run from the same puppet server?Yes.> Have you seen any type of scaling issue there?"No issues with increasing size, either technical or social, thus far."> I''ve been thinking about the possibility of having kind of a tree setup, > where you have a puppet "metaserver" (a puppet server able to configure > child puppet servers) and then a number of puppet servers with their > corresponding clients... what do you think of this?You''ll probably have to have separate CAs, and you''ll lose a lot of the advantages of object export and collection. There''s also the issue of getting the manifests out to all of the "end" servers, although that''s pretty simple to solve. - Matt -- "You keep using that word. I do not think it means what you think it means." -- Inigo, The Princess Bride
On 03/10/06, Matt Palmer <mpalmer@hezmatt.org> wrote:> On Tue, Oct 03, 2006 at 10:32:53AM +1000, Matthew Flanagan wrote: > > I have to ask: Is anyone running puppet in a large environment? i.e. > > between 100 and 1000 hosts? > > I''d probably have that many running around by now. No issues with > increasing size, either technical or social, thus far.How many exactly? What kind of hardware & OS is your puppet server running on? What level of system resources is it consuming? load, CPU, memory, IO? How large is your manifest(s)?> > - Matt > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
On Tue, Oct 03, 2006 at 10:26:39PM +1000, Matthew Flanagan wrote:> On 03/10/06, Matt Palmer <mpalmer@hezmatt.org> wrote: > > On Tue, Oct 03, 2006 at 10:32:53AM +1000, Matthew Flanagan wrote: > > > I have to ask: Is anyone running puppet in a large environment? i.e. > > > between 100 and 1000 hosts? > > > > I''d probably have that many running around by now. No issues with > > increasing size, either technical or social, thus far. > > How many exactly? > What kind of hardware & OS is your puppet server running on? > What level of system resources is it consuming? load, CPU, memory, IO? > How large is your manifest(s)?Getting rather demanding, aren''t we? - Matt
-----Original Message----- From: Matthew Palmer <mpalmer@hezmatt.org> Date: Tuesday, Oct 3, 2006 5:35 pm Subject: Re: [Puppet-users] 41 server under puppet today On Tue, Oct 03, 2006 at 10:26:39PM +1000, Matthew Flanagan wrote: On 03/10/06, Matt Palmer <mpalmer@hezmatt.org> wrote: > On Tue, Oct 03, 2006 at 10:32:53AM +1000, Matthew Flanagan wrote: > > I have to ask: Is anyone running puppet in a large environment? i.e. > > between 100 and 1000 hosts? > > I''d probably have that many running around by now. No issues with > increasing size, either technical or social, thus far. How many exactly? What kind of hardware & OS is your puppet server running on? What level of system resources is it consuming? load, CPU, memory, IO? How large is your manifest(s)? Getting rather demanding, aren''t we? - Matt I don''t think it''s demanding at all - I''m interested as well. If you''re not interested/comfortable in sharing, just say so. -- Ryan Schwartz Joyent, Inc TextDrive, Inc.
On Tue, Oct 03, 2006 at 07:18:00PM -0500, Ryan Schwartz wrote:> On Tue, Oct 03, 2006 at 10:26:39PM +1000, Matthew Flanagan wrote: > On 03/10/06, Matt Palmer <mpalmer@hezmatt.org> wrote: > > On Tue, Oct 03, 2006 at 10:32:53AM +1000, Matthew Flanagan wrote: > > > I have to ask: Is anyone running puppet in a large environment? i.e. > > > between 100 and 1000 hosts? > > > > I''d probably have that many running around by now. No issues with > > increasing size, either technical or social, thus far. > > How many exactly? > What kind of hardware & OS is your puppet server running on? > What level of system resources is it consuming? load, CPU, memory, IO? > How large is your manifest(s)? > > Getting rather demanding, aren''t we? > > - Matt > > I don''t think it''s demanding at all - I''m interested as well. > > If you''re not interested/comfortable in sharing, just say so.Primarily, I''m not comfortable doing a complete audit of all of the Puppet-managed equipment and all of my manifests at this client to answer a mailing list question; although I''m also mindful of the NDA aspects. - Matt
On 04/10/06, Matthew Palmer <mpalmer@hezmatt.org> wrote:> On Tue, Oct 03, 2006 at 07:18:00PM -0500, Ryan Schwartz wrote: > > On Tue, Oct 03, 2006 at 10:26:39PM +1000, Matthew Flanagan wrote: > > On 03/10/06, Matt Palmer <mpalmer@hezmatt.org> wrote: > > > On Tue, Oct 03, 2006 at 10:32:53AM +1000, Matthew Flanagan wrote: > > > > I have to ask: Is anyone running puppet in a large environment? i.e. > > > > between 100 and 1000 hosts? > > > > > > I''d probably have that many running around by now. No issues with > > > increasing size, either technical or social, thus far. > > > > How many exactly? > > What kind of hardware & OS is your puppet server running on? > > What level of system resources is it consuming? load, CPU, memory, IO? > > How large is your manifest(s)? > > > > Getting rather demanding, aren''t we? > > > > - Matt > > > > I don''t think it''s demanding at all - I''m interested as well. > > > > If you''re not interested/comfortable in sharing, just say so. > > Primarily, I''m not comfortable doing a complete audit of all of the > Puppet-managed equipment and all of my manifests at this client to answer a > mailing list question; although I''m also mindful of the NDA aspects.I apologize for the tone of my previous email, I was holding a baby in one arm and pecking at the keyboard with the other. Regardless, this is the same problem the cfengine community has. Organisations are *allegedly* managing 1000''s of hosts with cfengine but as soon as you try and get anyone to talk about it they clam up. It doesn''t really help promote the use of cfengine (or puppet) in managing large environments. Having hard facts, reference sites etc does. Send me an NDA. I''ll be happy to sign it.> > - Matt > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
Matthew Flanagan wrote:> > I apologize for the tone of my previous email, I was holding a baby in > one arm and pecking at the keyboard with the other. > > Regardless, this is the same problem the cfengine community has. > Organisations are *allegedly* managing 1000''s of hosts with cfengine > but as soon as you try and get anyone to talk about it they clam up. > It doesn''t really help promote the use of cfengine (or puppet) in > managing large environments. Having hard facts, reference sites etc > does.I basically agree with this -- I''d love to have references pointing to hundreds or thousands of nodes being managed by Puppet. However, you don''t really get that for any tool, as far as I can tell -- the best one can usually hope for is a list of organizations using the product. I just noticed Nagios has a User Profile page; it''d be great to have something like that for Puppet, maybe with an anonymizer. I will say that my original expression of concern about performance was more like motherly concern than experience -- I''m always afraid that Puppet''s going to accidentally destroy the Earth, so it''s reasonable that I''m also afraid it''ll be a bit slow (but at least that''ll give us a bit more time to save the Earth). There''s a *lot* of headroom for optimizing Puppet''s performance -- it''s just a simple web server, so you can scale as horizontally as you want, like any other web server. In addition, I''m currently using a reknownedly slow web server (Webrick); I expect I could get significant speed increases by switching to Mongrel or maybe mod_ruby or FCGI, especially when it comes to parallelization and many clients. The fact that this apparently hasn''t come up for anyone is a good sign, as far as I can tell. -- The remarkable thing about Shakespeare is that he really is very good, in spite of all the people who say he is very good. -- Robert Graves --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Wed, Oct 04, 2006 at 11:59:40AM +1000, Matthew Flanagan wrote:> Regardless, this is the same problem the cfengine community has. > Organisations are *allegedly* managing 1000''s of hosts with cfengine > but as soon as you try and get anyone to talk about it they clam up. > It doesn''t really help promote the use of cfengine (or puppet) in > managing large environments. Having hard facts, reference sites etc > does.Have you produced a case study on the use of any other open source tools in your organization that are publically available? Writing a case study is a painful business. My employer got a case study done for a combination of CFEngine, Nagios, revision control, and Novell products all working together at a client site. They paid a chunk to get it written, too, if I recall correctly. Hasn''t done them a whole lot of good, from what I can tell -- then again, we''re not exactly pushing new CFEngine deployments at this stage, but this Puppet deployment is something of a pilot, so we''re not pushing Puppet real heavily yet, either. A case study might come out of this site, but I don''t know if it''d be public, and it wouldn''t just concentrate on Puppet, although Puppet would feature fairly heavily. Are you willing to be a reference site if you get Puppet up and running? If you commit to doing a case study of your Puppet deployment, I''m fairly sure you''d get insane amounts of support from Luke and the rest of the community, but you get pretty good support for free anyway. I''d say that even if there *were* performance problems to begin with, there wouldn''t be for very long. <grin>> Send me an NDA. I''ll be happy to sign it.It''s not my information to disclose, I''m afraid -- I''m just a contractor to the client. If it *were* my information, you wouldn''t need the NDA. - Matt -- Sure, it''s possible to write C in an object-oriented way. But, in practice, getting an entire team to do that is like telling them to walk along a straight line painted on the floor, with the lights off. -- Tess Snider, slug-chat@slug.org.au
On 04/10/06, Matthew Palmer <mpalmer@hezmatt.org> wrote:> On Wed, Oct 04, 2006 at 11:59:40AM +1000, Matthew Flanagan wrote: > > Regardless, this is the same problem the cfengine community has. > > Organisations are *allegedly* managing 1000''s of hosts with cfengine > > but as soon as you try and get anyone to talk about it they clam up. > > It doesn''t really help promote the use of cfengine (or puppet) in > > managing large environments. Having hard facts, reference sites etc > > does. > > Have you produced a case study on the use of any other open source tools in > your organization that are publically available? > > Writing a case study is a painful business. My employer got a case study > done for a combination of CFEngine, Nagios, revision control, and Novell > products all working together at a client site. They paid a chunk to get it > written, too, if I recall correctly. Hasn''t done them a whole lot of good, > from what I can tell -- then again, we''re not exactly pushing new CFEngine > deployments at this stage, but this Puppet deployment is something of a > pilot, so we''re not pushing Puppet real heavily yet, either. A case study > might come out of this site, but I don''t know if it''d be public, and it > wouldn''t just concentrate on Puppet, although Puppet would feature fairly > heavily.My employer has been involved in numerous case studies across many industry sectors (not just IT) to the benefit of both the vendor and themselves, but thats not what I''m after. Simple, anonymous numbers is all I was asking for, not business plans and trade secrets.> > Are you willing to be a reference site if you get Puppet up and running? > If you commit to doing a case study of your Puppet deployment, I''m fairly > sure you''d get insane amounts of support from Luke and the rest of the > community, but you get pretty good support for free anyway. I''d say that > even if there *were* performance problems to begin with, there wouldn''t be > for very long. <grin>From my experience being a reference site equates to pain and the business I''m in can''t suffer that. Besides I need to justify to the business why I want to use puppet and produce a reliable solution that will scale in our environment. So far I''ve seen no evidence of this except for one user with 41 clients that is having performance issues and your offering that you maybe have somewhere between 1 and 1000 clients with "No issues with increasing size, either technical or social, thus far." Hardly quantitative. I can approach just about any vendor I deal with and ask them for a customer refererence that is willing to talk formally or informally about their designs and implementations, warts and all. User mailing lists and conferences are generally the same and very valuable when it comes to making an informed choice. regards matthew> > Send me an NDA. I''ll be happy to sign it. > > It''s not my information to disclose, I''m afraid -- I''m just a contractor to > the client. If it *were* my information, you wouldn''t need the NDA. > > - Matt > > -- > Sure, it''s possible to write C in an object-oriented way. But, in practice, > getting an entire team to do that is like telling them to walk along a > straight line painted on the floor, with the lights off. > -- Tess Snider, slug-chat@slug.org.au > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
> From my experience being a reference site equates to pain and the > business I''m in can''t suffer that. Besides I need to justify to the > business why I want to use puppet and produce a reliable solution that > will scale in our environment. So far I''ve seen no evidence of this > except for one user with 41 clients that is having performance issues > and your offering that you maybe have somewhere between 1 and 1000 > clients with "No issues with increasing size, either technical or > social, thus far." Hardly quantitative. >let just be a little relative to that, 5 hosts have performances issues the other do not. Those are not real servers but virtual servers or jail if you prefer. So for 36 of them the recipe are executed in 12 second in average, for those 5 it takes ages and i havent found where (i am NOT actively searching for i must admit..). My post was just there to say to Luke and other that i use puppet for freeBSD host, i only have 41 servers right now so this can be seen as a micro tiny deployement :) regards, Ghislain. _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Matthew Flanagan wrote:> > From my experience being a reference site equates to pain and the > business I''m in can''t suffer that. Besides I need to justify to the > business why I want to use puppet and produce a reliable solution that > will scale in our environment. So far I''ve seen no evidence of this > except for one user with 41 clients that is having performance issues > and your offering that you maybe have somewhere between 1 and 1000 > clients with "No issues with increasing size, either technical or > social, thus far." Hardly quantitative.>> I can approach just about any vendor I deal with and ask them for a > customer refererence that is willing to talk formally or informally > about their designs and implementations, warts and all. User mailing > lists and conferences are generally the same and very valuable when it > comes to making an informed choice.If you''re not in a position to do a prototype, or your clients are conservative enough that they require quantitative data demonstrating a product''s suitability, then you are likely to have to avoid the majority of the open-source world and Puppet is likely not appropriate for you or your clients at this point. As Matt said, I provide good support even to non-clients (my wife probably wishes I provided a bit less support to #puppet and a bit more to my house), and I make sure my clients have what they want in terms of performance and support. If this is not sufficient for your clients, then it is likely they would prefer a more corporate solution like BladeLogic or OpsWare, which cost $100k just to walk in the door and usually end up costing more than $1m. At this point, I''m more of a consultant than a vendor, I just happen to be the primary author of the software I''m doing consulting in. I tried being a consultant with cfengine, but I could not provide the level of support for cfengine that my clients demanded, since it was difficult to get patches committed to trunk (heck, Mark wasn''t even using version control at the time, so there was no trunk). Like any other product, and especially open source products with as short a history as Puppet''s, you''ll need to do your own vetting until it''s been around for a couple of years. There are clients doing production work, and most or all of them are pretty damn happy with Puppet, but almost none of them happen to be talking about it at this point. If that makes you uncomfortable, then check back in a year when it suits your needs better. Or, check out bcfg2, which has been in production for longer than Puppet''s been announced; it might suit your needs well there, although I personally am not fond of its approach. -- The Chico, California, City Council enacted a ban on nuclear weapons, setting a $500 fine for anyone detonating one within city limits. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 05/10/06, Luke Kanies <luke@madstop.com> wrote:> Matthew Flanagan wrote: > > > > From my experience being a reference site equates to pain and the > > business I''m in can''t suffer that. Besides I need to justify to the > > business why I want to use puppet and produce a reliable solution that > > will scale in our environment. So far I''ve seen no evidence of this > > except for one user with 41 clients that is having performance issues > > and your offering that you maybe have somewhere between 1 and 1000 > > clients with "No issues with increasing size, either technical or > > social, thus far." Hardly quantitative. > > > > I can approach just about any vendor I deal with and ask them for a > > customer refererence that is willing to talk formally or informally > > about their designs and implementations, warts and all. User mailing > > lists and conferences are generally the same and very valuable when it > > comes to making an informed choice. > > If you''re not in a position to do a prototype, or your clients are > conservative enough that they require quantitative data demonstrating a > product''s suitability, then you are likely to have to avoid the majority > of the open-source world and Puppet is likely not appropriate for you or > your clients at this point. >I said previously that I am testing in my lab and the 10 hosts I have there represent only 2% of my potential install base. I cannot assume how far it can scale. Thus my question to the puppet user community. I would ask this question regardless of the whether the software was open or closed source. This thread is diverging from that.> As Matt said, I provide good support even to non-clients (my wife > probably wishes I provided a bit less support to #puppet and a bit more > to my house), and I make sure my clients have what they want in terms of > performance and support. If this is not sufficient for your clients, > then it is likely they would prefer a more corporate solution like > BladeLogic or OpsWare, which cost $100k just to walk in the door and > usually end up costing more than $1m. > > At this point, I''m more of a consultant than a vendor, I just happen to > be the primary author of the software I''m doing consulting in. I tried > being a consultant with cfengine, but I could not provide the level of > support for cfengine that my clients demanded, since it was difficult to > get patches committed to trunk (heck, Mark wasn''t even using version > control at the time, so there was no trunk). >I have submitted patches to cfengine in the past that were accepted. One of the reasons for me avoiding cfengine was a result of this and seeing the state of its code. I think I''m still listed as the cfengine package maintainer in Fink.> Like any other product, and especially open source products with as > short a history as Puppet''s, you''ll need to do your own vetting until > it''s been around for a couple of years. There are clients doing > production work, and most or all of them are pretty damn happy with > Puppet, but almost none of them happen to be talking about it at this > point. If that makes you uncomfortable, then check back in a year when > it suits your needs better. Or, check out bcfg2, which has been in > production for longer than Puppet''s been announced; it might suit your > needs well there, although I personally am not fond of its approach. > > -- > The Chico, California, City Council enacted a ban on nuclear weapons, > setting a $500 fine for anyone detonating one within city limits. > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
Matthew Flanagan wrote:> > I said previously that I am testing in my lab and the 10 hosts I have > there represent only 2% of my potential install base. I cannot assume > how far it can scale. Thus my question to the puppet user community. I > would ask this question regardless of the whether the software was > open or closed source. This thread is diverging from that.Ah, ok; I missed that, I guess. I know I''ve got a client that planned on putting Puppet on 1000+ nodes, but they have always been pretty uncommunicative, so I don''t know how far their deployment has come. I''ve got another client with plans for a couple hundred, but they''re in a very early phase. Otherwise, the best I can say is that I do offer (very reasonably priced) support contracts, and Puppet was specifically written to support horizontal scaling and I''ve made essentially no performance optimizations to date so I know there''s plenty of headroom for making it faster. I think that''s the best one can get right now in terms of maturity. Puppet is still pretty immature, as the version number attests.> I have submitted patches to cfengine in the past that were accepted. > One of the reasons for me avoiding cfengine was a result of this and > seeing the state of its code. I think I''m still listed as the cfengine > package maintainer in Fink.I''ve had lots of small patches accepted to cfengine, but nothing large-scale, and certainly nothing that would have qualified as refactoring. Mark seemed pretty opposed to the idea that cfengine might even have needed some refactoring. I actually forked cfengine at one point to try to fix it myself, but I eventually decided it was less work to start from scratch (in a more powerful language). -- I have an answering machine in my car. It says, "I''m home now. But leave a message and I''ll call when I''m out. -- Stephen Wright --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Thu, 2006-10-05 at 08:22 +1000, Matthew Flanagan wrote:> I said previously that I am testing in my lab and the 10 hosts I have > there represent only 2% of my potential install base. I cannot assume > how far it can scale. Thus my question to the puppet user community. I > would ask this question regardless of the whether the software was > open or closed source. This thread is diverging from that.Not that it really solves your problem, but have you considered using some sort of virtualization on those test hosts ? With that you should be able to increase your effective number of hosts by a factor of 5-10, which should give you a better picture of puppet''s scalability (and I am sure everybody on this list would love to hear what you find ;) And as Luke said: puppet is designed in a way that makes it easy to scale horizontally by adding more puppetmasters; just share all the files puppetmaster needs (manifests and files served through the manifest, /etc/puppet, /var/lib/puppet/ssl) via NFS or similar. That will let you run several puppetmaster servers behind a loadbalancing firewall (or with round-robin DNS) ... even if that doesn''t seem ideal, it should at least give you some piece of mind that there is a relatively easy way out should puppet not scale to the number of clients you need it to scale to. David
On Thu, Oct 05, 2006 at 12:36:25PM +0200, David Lutterkort wrote:> And as Luke said: puppet is designed in a way that makes it easy to > scale horizontally by adding more puppetmasters; just share all the > files puppetmaster needs (manifests and files served through the > manifest, /etc/puppet, /var/lib/puppet/ssl) via NFS or similar. > [...]I think that it might be useful to extend the mechanism currently used by clients to fetch configuration, to allow server to server replication. Has anyone given any thought to having a "zoned" configuration? By that -- Ceri Storey <cez@necrofish.org.uk> ''What I really want is "apt-get smite"'' --Rob Partington <http://rjp.frottage.org>
On Tue, Oct 03, 2006 at 08:03:55PM +1000, Matthew Palmer wrote:> > I''ve been thinking about the possibility of having kind of a tree setup, > > where you have a puppet "metaserver" (a puppet server able to configure > > child puppet servers) and then a number of puppet servers with their > > corresponding clients... what do you think of this? > > You''ll probably have to have separate CAs, and you''ll lose a lot of the > advantages of object export and collection. There''s also the issue of > getting the manifests out to all of the "end" servers, although that''s > pretty simple to solve.However, this kind of topology layout might be useful in the case where you need to split your infrastructure into seperate zones--the closest analogy I can think of at the moment would be to OSPF areas, where the "master master" server (or backbone) would have knowledge of all configuration for all zones, wheras each metaserver for each zone would only know about the configuration for each zone. To take a trivial example, you might have a set of internal hosts named {fred,barney}.int.example.com, and a set in a DMZ called say {wilma,betty}.dmz.example.com. Now, assuming that: * We want to be able to manage all hosts from one central point * Hosts in the internal area can connect to those in the DMZ, but not vica versa * No host in the DMZ area should have knowlege of any in the internal area This implies that configuration information from the internal puppet server must be pushed to the DMZ puppet server, ensuring that only the appropriate information is transferred. You could of course do this using mechnisms which are external to puppet (eg: use rsync, including only a subset of the configuration), but it might well be cleaner to include this functionality natively. It''s a specific case of problem, but I''m willing to bet that it''s a problem that lots of companies have. Eg: I can see it being a problem for those who offer managed services to their customers. As for the CA issue Matthew mentioned, I don''t see that there''s any problem with treating the master server as a root CA, which would then delegate some responsibility to each metaserver, much like how regular SSL certificate providers do. A reasonable default policy might be only trust hosts whose certificates have been signed by the local CA, and not bother following certificate chains. That should probably be configurable, though. -- Ceri Storey <cez@necrofish.org.uk> ''What I really want is "apt-get smite"'' --Rob Partington <http://rjp.frottage.org>
Ceri Storey wrote:> On Tue, Oct 03, 2006 at 08:03:55PM +1000, Matthew Palmer wrote: >> You''ll probably have to have separate CAs, and you''ll lose a lot of the >> advantages of object export and collection. There''s also the issue of >> getting the manifests out to all of the "end" servers, although that''s >> pretty simple to solve.You shouldn''t need entirely separate CAs -- you''d have to hack things a bit, but each non-top-level master would need a CA cert signed by the top-level CA. SSL already supports this with no problem, but Puppet''s CA support does not yet make it easy. So, if you need this, you can gen the certs yourself, or you can add support for it into Puppet, neither of which is prohibitively difficult.> However, this kind of topology layout might be useful in the case where > you need to split your infrastructure into seperate zones--the closest > analogy I can think of at the moment would be to OSPF areas, where the > "master master" server (or backbone) would have knowledge of all > configuration for all zones, wheras each metaserver for each zone would > only know about the configuration for each zone. > > To take a trivial example, you might have a set of internal hosts named > {fred,barney}.int.example.com, and a set in a DMZ called say > {wilma,betty}.dmz.example.com. Now, assuming that:I can certainly see an organization having multiple zones, each with their own sub-CA and set of configurations. They''d probably share a lot of Puppet code but have different node configurations or something.> * We want to be able to manage all hosts from one central point > * Hosts in the internal area can connect to those in the DMZ, but not vica versa > * No host in the DMZ area should have knowlege of any in the internal area > > This implies that configuration information from the internal puppet server > must be pushed to the DMZ puppet server, ensuring that only the > appropriate information is transferred. > > You could of course do this using mechnisms which are external to puppet > (eg: use rsync, including only a subset of the configuration), but it > might well be cleaner to include this functionality natively.Don''t tell anyone, but this functionality already exists. There''s currently no mechanism for retrieving facts from the DMZ machines, so that would have to be added (and would take about 10 seconds), but you can already push configurations to machines, using the ''pelement'' server. It''s all experimental, blah blah, but it works.> It''s a specific case of problem, but I''m willing to bet that it''s a > problem that lots of companies have. Eg: I can see it being a > problem for those who offer managed services to their customers.Yeah.> As for the CA issue Matthew mentioned, I don''t see that there''s any problem > with treating the master server as a root CA, which would then delegate > some responsibility to each metaserver, much like how regular SSL > certificate providers do. A reasonable default policy might be only > trust hosts whose certificates have been signed by the local > CA, and not bother following certificate chains. That should probably > be configurable, though.Hmmm. At this point, CA trust is determined at the SSL layer, so I don''t even see that. You still have authorization after that, though, based on hostname and/or IP address. -- I have lost friends, some by death... others through sheer inability to cross the street. -- Virginia Woolf --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com