RE: puppet
The articles appear to be referring to the footprint of the tool rather than the scalability. The aim for us is to support O(100K) clients and we can accept some hardware investment in a scale-out architecture to achieve this. The approach is not a 'developer' one but an infrastructure manager looking at total cost of ownership which includes more than hardware costs. We've certainly found major productivity gains from tools such as PuppetDB and Heira along with manifests from the puppetforge such as the OpenStack one. As you say, the most important thing is to do configuration management, the tool choice is secondary and different sites will have different needs. Tim > -Original Message- > From: Natxo Asenjo [mailto:natxo.ase...@gmail.com] > Sent: 22 February 2013 23:18 > To: Tim Bell > Cc: Yasha Karant; SCIENTIFIC-LINUX-USERS@FNAL.GOV > Subject: Re: puppet > > On Fri, Feb 22, 2013 at 6:54 PM, Tim Bell wrote: > > > > I'm not sure where the statement that Puppet does not scale well comes > > from... > > it is pretty well documented by Jarle Bjørgeengen for ;login (usenix): > > https://www.usenix.org/publications/login/february-2010-volume-35-number- > 1/puppet-and-cfengine-compared-time-and-resource > > This one is more recent: > > http://www.blogcompiler.com/2012/09/30/scalability-of-cfengine-and-puppet- > 2/ > > And another happy puppet user: > > http://my.opera.com/marcomarongiu/blog/2012/06/17/why-i-gave-up-puppet- > and-chose-cfengine-3 > > > You do need to have enough puppet masters and architect it according > > to the best practises but the books tell you how to do this. > > exactly, a developer solution to every problem: throw more hardware at it, > hardware is cheap ;-) > > Specially in virtual environments puppet is a resource hog if you compare it > to > cfengine. I have exactly one cfengine policy host controlling nearly 400 > hosts. > Its load is nearly always 0. This is quite normal. The policy host has 3 > different > sets of policies: test, staging and production. This is a vm with a grand > 256Mb > ram and 1 vcpu. This host is our kickstart/fai installation server as well. > > SPOF you may think. Not really, hosts cache their policies, so when the policy > master needs patching, whatever, we just do it. The hosts apply their cached > policies. > > I am pretty much sure I could not run the same load with the same hardware > with puppet (actually, I know, I tested it). > > O well, in the end as long as people use something sane I am happy. > -- > natxo smime.p7s Description: S/MIME cryptographic signature
[ot] Re: Perl config scripts, was Re: puppet
On Sat, Feb 23, 2013 at 2:32 PM, Nico Kadel-Garcia wrote: > On Sat, Feb 23, 2013 at 7:46 AM, Natxo Asenjo wrote: >> On Fri, Feb 22, 2013 at 5:24 PM, Nico Kadel-Garcia wrote: >> yes, people seem to never have heard of local::lib and get themselves >> in terrible troubles ;-) > > *Tell* me about it. I spent a great deal of time a few years back > backporting Apache 1.3 to one of the moral equivalents of Scientific > Linux 4, because the oroginal software relied on the old mod_perl > package. *dozens* of dependencies. never came accross that (lucky me!), but you can always create your own mini-cpan and install the modules you need from there or ask cpan(m) nicely to do it for you. See http://stackoverflow.com/questions/260593/how-can-i-install-a-specific-version-of-a-perl-module >>> Fortunately, for SL and other upstream vendor based modules, it's >>> often possible to find them in 3rdparty repositories, especially loo, >>> in Fedora for backporting, or to use tools like "cpan2rpm" or >>> "cpanspec" to build RPM's for them which you can deploy in an internal >>> yum repository or for direct installation via cfengine or puppet. >>> similar techniques work well for PHP and Ruby modules as well. >>> >>> I actually publish a whole stack of these over at >>> https://github.com/nkadel/. And i'm happy to show other people how to >>> set up build environments for that. >> >> it's cool to see what you have done, but really, these days building >> custom Perls and deploying them side by side system Perl is a very >> easy: perlbrew, cpanminus, cpan-outdated. You get the best of both >> worlds. New modern Perl goodies for modern times, legacy Perl for >> older enterprise systems. > > It can get. awkward. You hve to essentially mantain a separate > toolchain, and lose the dependency tracking and version tracking that > you get with RPM or any sane package management system. Well, this is part of the job ;-) ; there is life outside the official repositories and although it would be lovely to have everything in nicely packaged in actively maintained repos, that is not always feasible. So yes, keeping a software repository for the company and testing it is part of our job (this was too in 'The practice of system and network administration' by Limoncelli et al, by the way). >> We deploy several Perls to our environments and adding new modules is >> just a cpanm away in one place, the changes get picked up and are >> distributed to the hosts. > > And *that* is exactly the problem. Deployment is easy. Cleanup of old > components, especially as different versions of different packages > pick up the same module names? Not so easy. clean up is just a question of removing files from the source. We leave the system Perl alone, so there are no collisions. In the hypothetical event two apps had conflicting modules, then we would have use the perlbrew lib facility which takes care of all that (see http://perlbrew.pl/Install-a-sitecustomize.pl-file-with-perlbrew.html). >> Works a treat. > > Until it doesn't, which I'm afraid I've encountered headlong. The > problem isn't making your own, local toolchains, it's the hidden > module dependencies. I encountered this with mod_perl some years back: > a project needed to use an older mod_perl, and building the toolchain > from CPAN led to circular dependencies each calling the most recent > version of the other components, which depended on other recent > components, which depended on a more recent version of mod_perl. > Hilariity ensued. I had to build RPM's for *each individual module", > rename them from "perl-foo-bar" to "project-perl-foo-bar" to get them > out of the yum update chain, or I'd have had to rewrite all the > original source code to do what you originally suggested: look in a > locally managed directory, first. what you are describing is the reason we do not touch the system's Perl and why before deploying something the requirements must be very specific. Usually most times the troubles will be the other way round: our favourite linux vendor distributes a hopelessly outdated version of Perl. They know it, they don't care. So developers have worked around this and their solutions are clean, easy and unobtrusive. I cannot blame them. I know this used to be a huge problem. I have had more than enough problems myself getting all the modules to get Request Tracker up and running, for instance. But now it just works out of the tarball. And that is priceless. Any way, this is way off topic now. -- groet, natxo
Re: Perl config scripts, was Re: puppet
I absolutely agree I created my first custom rpm way back in 1996 and I never turned back. the only thing I use cpan for is to quickly figure out the dependency chain before I create an rpm. And I don't understand why more people don't do it especially since tools like cpan2rpm started to become available. But to be fair Perl isn't the only language where I've seen people do this, I've seen PHP, Python, C and Java developers do it to.Oh the highginks that insued while trying to figure out why a companies web site didn't work on the new web server with what I thought was an identical build, while a developer who had forgotten what they did was standing over my shoulder saying "is it working yet" over and over again. Those happy memories make me smile every time I think of them.-- Sent from my HP Pre3On Feb 23, 2013 8:32 AM, Nico Kadel-Garcia wrote: On Sat, Feb 23, 2013 at 7:46 AM, Natxo Asenjo wrote: > On Fri, Feb 22, 2013 at 5:24 PM, Nico Kadel-Garcia wrote: >> As long as you package the modules, you can get away with this. One of >> the painful difficulties comes when people put "cpan build Foo::bar" >> for the Foo:::Bar module to enable features on their deployed systems, >> built right into their config scripts or testing tools or instlalers, >> and wind up displacing system versions of core utilities. This can, >> and has, included accidentally replacing Perl itself at various times >> to get various updated modules. > > yes, people seem to never have heard of local::lib and get themselves > in terrible troubles ;-) *Tell* me about it. I spent a great deal of time a few years back backporting Apache 1.3 to one of the moral equivalents of Scientific Linux 4, because the oroginal software relied on the old mod_perl package. *dozens* of dependencies. >> Fortunately, for SL and other upstream vendor based modules, it's >> often possible to find them in 3rdparty repositories, especially loo, >> in Fedora for backporting, or to use tools like "cpan2rpm" or >> "cpanspec" to build RPM's for them which you can deploy in an internal >> yum repository or for direct installation via cfengine or puppet. >> similar techniques work well for PHP and Ruby modules as well. >> >> I actually publish a whole stack of these over at >> https://github.com/nkadel/. And i'm happy to show other people how to >> set up build environments for that. > > it's cool to see what you have done, but really, these days building > custom Perls and deploying them side by side system Perl is a very > easy: perlbrew, cpanminus, cpan-outdated. You get the best of both > worlds. New modern Perl goodies for modern times, legacy Perl for > older enterprise systems. It can get. awkward. You hve to essentially mantain a separate toolchain, and lose the dependency tracking and version tracking that you get with RPM or any sane package management sysstem. > We deploy several Perls to our environments and adding new modules is > just a cpanm away in one place, the changes get picked up and are > distributed to the hosts. And *that* is exactly the problem. Deployment is easy. Cleanup of old components, especially as different versions of different packages pick up the same module names? Not so easy. > Works a treat. Until it doesn't, which I'm afraid I've encountered headlong. The problem isn't making your own, local toolchains, it's the hidden module dependencies. I encountered this with mod_perl some years back: a project needed to use an older mod_perl, and building the toolchain from CPAN led to circular dependencies each calling the most recent version of the other components, which depended on other recent components, which depended on a more recent version of mod_perl. Hilariity ensued. I had to build RPM's for *each individual module", rename them from "perl-foo-bar" to "project-perl-foo-bar" to get them out of the yum update chain, or I'd have had to rewrite all the original source code to do what you originally suggested: look in a locally managed directory, first.
Re: Perl config scripts, was Re: puppet
On Sat, Feb 23, 2013 at 7:46 AM, Natxo Asenjo wrote: > On Fri, Feb 22, 2013 at 5:24 PM, Nico Kadel-Garcia wrote: >> As long as you package the modules, you can get away with this. One of >> the painful difficulties comes when people put "cpan build Foo::bar" >> for the Foo:::Bar module to enable features on their deployed systems, >> built right into their config scripts or testing tools or instlalers, >> and wind up displacing system versions of core utilities. This can, >> and has, included accidentally replacing Perl itself at various times >> to get various updated modules. > > yes, people seem to never have heard of local::lib and get themselves > in terrible troubles ;-) *Tell* me about it. I spent a great deal of time a few years back backporting Apache 1.3 to one of the moral equivalents of Scientific Linux 4, because the oroginal software relied on the old mod_perl package. *dozens* of dependencies. >> Fortunately, for SL and other upstream vendor based modules, it's >> often possible to find them in 3rdparty repositories, especially loo, >> in Fedora for backporting, or to use tools like "cpan2rpm" or >> "cpanspec" to build RPM's for them which you can deploy in an internal >> yum repository or for direct installation via cfengine or puppet. >> similar techniques work well for PHP and Ruby modules as well. >> >> I actually publish a whole stack of these over at >> https://github.com/nkadel/. And i'm happy to show other people how to >> set up build environments for that. > > it's cool to see what you have done, but really, these days building > custom Perls and deploying them side by side system Perl is a very > easy: perlbrew, cpanminus, cpan-outdated. You get the best of both > worlds. New modern Perl goodies for modern times, legacy Perl for > older enterprise systems. It can get. awkward. You hve to essentially mantain a separate toolchain, and lose the dependency tracking and version tracking that you get with RPM or any sane package management sysstem. > We deploy several Perls to our environments and adding new modules is > just a cpanm away in one place, the changes get picked up and are > distributed to the hosts. And *that* is exactly the problem. Deployment is easy. Cleanup of old components, especially as different versions of different packages pick up the same module names? Not so easy. > Works a treat. Until it doesn't, which I'm afraid I've encountered headlong. The problem isn't making your own, local toolchains, it's the hidden module dependencies. I encountered this with mod_perl some years back: a project needed to use an older mod_perl, and building the toolchain from CPAN led to circular dependencies each calling the most recent version of the other components, which depended on other recent components, which depended on a more recent version of mod_perl. Hilariity ensued. I had to build RPM's for *each individual module", rename them from "perl-foo-bar" to "project-perl-foo-bar" to get them out of the yum update chain, or I'd have had to rewrite all the original source code to do what you originally suggested: look in a locally managed directory, first.
Re: Perl config scripts, was Re: puppet
On Fri, Feb 22, 2013 at 5:24 PM, Nico Kadel-Garcia wrote: > [ Changing thread title to handle Perls of wisdom] > > On Fri, Feb 22, 2013 at 11:04 AM, Graham Allan wrote: > >> Just as we here still write most of our support scripts etc in perl, that is >> also unfashionable now, doesn't mean it's not the best tool for the job (fx: >> throws bomb and runs away... :-) >> >> Graham > > As long as you package the modules, you can get away with this. One of > the painful difficulties comes when people put "cpan build Foo::bar" > for the Foo:::Bar module to enable features on their deployed systems, > built right into their config scripts or testing tools or instlalers, > and wind up displacing system versions of core utilities. This can, > and has, included accidentally replacing Perl itself at various times > to get various updated modules. yes, people seem to never have heard of local::lib and get themselves in terrible troubles ;-) > Fortunately, for SL and other upstream vendor based modules, it's > often possible to find them in 3rdparty repositories, especially loo, > in Fedora for backporting, or to use tools like "cpan2rpm" or > "cpanspec" to build RPM's for them which you can deploy in an internal > yum repository or for direct installation via cfengine or puppet. > similar techniques work well for PHP and Ruby modules as well. > > I actually publish a whole stack of these over at > https://github.com/nkadel/. And i'm happy to show other people how to > set up build environments for that. it's cool to see what you have done, but really, these days building custom Perls and deploying them side by side system Perl is a very easy: perlbrew, cpanminus, cpan-outdated. You get the best of both worlds. New modern Perl goodies for modern times, legacy Perl for older enterprise systems. We deploy several Perls to our environments and adding new modules is just a cpanm away in one place, the changes get picked up and are distributed to the hosts. Works a treat. -- natxo
Re: puppet
On Fri, Feb 22, 2013 at 6:54 PM, Tim Bell wrote: > > I'm not sure where the statement that Puppet does not scale well comes > from... it is pretty well documented by Jarle Bjørgeengen for ;login (usenix): https://www.usenix.org/publications/login/february-2010-volume-35-number-1/puppet-and-cfengine-compared-time-and-resource This one is more recent: http://www.blogcompiler.com/2012/09/30/scalability-of-cfengine-and-puppet-2/ And another happy puppet user: http://my.opera.com/marcomarongiu/blog/2012/06/17/why-i-gave-up-puppet-and-chose-cfengine-3 > You do need to have enough puppet masters and architect it according to the > best practises but the books tell you how to do this. exactly, a developer solution to every problem: throw more hardware at it, hardware is cheap ;-) Specially in virtual environments puppet is a resource hog if you compare it to cfengine. I have exactly one cfengine policy host controlling nearly 400 hosts. Its load is nearly always 0. This is quite normal. The policy host has 3 different sets of policies: test, staging and production. This is a vm with a grand 256Mb ram and 1 vcpu. This host is our kickstart/fai installation server as well. SPOF you may think. Not really, hosts cache their policies, so when the policy master needs patching, whatever, we just do it. The hosts apply their cached policies. I am pretty much sure I could not run the same load with the same hardware with puppet (actually, I know, I tested it). O well, in the end as long as people use something sane I am happy. -- natxo
Re: puppet
On Fri, Feb 22, 2013 at 7:04 PM, Tim Bell wrote: > ** ** > > If you have temporary staff, they would also be interested in having > Puppet skills on their CVs this is from job adverts trends on > indeed.com asking for particular skills in open posts. > > ** ** > > [image: puppet, cfengine Job Trends graph] > > > the curve looks impressive until you look at the percentages ;-), 0.05 vs 0.01. Huge market for both products. Interesting graph, let's see how it develops the next years. -- natxo <>
RE: puppet
The reason I settled on puppet was Windows support. I really prefer tools with support for Windows, Linux and Mac, and CFEngine was hugely expensive for the native windows agent. Puppet is free... Would I prefer scheduling for changes... yes. That said, it seems like it would be simple enough to use cron or something to move over a "new" module to your production area whenever you wanted it to "go"... -- James Pulver LEPP Computer Group Cornell University -Original Message- From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Paul Robert Marino Sent: Friday, February 22, 2013 11:40 AM To: Graham Allan Cc: Natxo Asenjo; SCIENTIFIC-LINUX-USERS@FNAL.GOV Subject: Re: puppet The only problem I ever had with cfengine is the documentation was never all that great but it is stable and scales well. That being said puppet is not perfect many of the stock recipes for it you find on the web don't scale well and to get it to scale you really need to be a ruby programer. My other issue with puppet is it doesn't provide you with a great amount of control over the timing of the deployment of changes unless you go to significant lengths. Essentially its good for a "Agile development model" environment which is popular with many web companies; however its a nightmare for mission critical 24x7x365 environments which require changes to be scheduled in advance. These days I'm using Spacewalk for most of what I would have used cfengine or puppet for in the past the only thing that it doesn't do out of the box is make sure that particular services are running or not running at boot, but there are a myriad of other simple ways to do that which require very little work, and if I really wanted to I could get spacewalk to do that as well via the soap APIs. On Fri, Feb 22, 2013 at 11:04 AM, Graham Allan wrote: > On 2/21/2013 4:13 PM, Natxo Asenjo wrote: >> >> On Thu, Feb 21, 2013 at 9:38 PM, Graham Allan >> wrote: >>> >>> >>> Also cfengine, though that seems to be getting less fashionable... We >>> still use it, no compelling reasons to change so far! >> >> >> we take our decisions based on functionality, not fashion. >> >> Cfengine is just fine. Good performance, little dependencies, good >> security record (not unimportant for your infrastructure management >> tool and oh what a start of the year for ruby it was), and it has in >> place editing instead of requiring you to use yet another tool >> (augeas). >> >> But puppet/chef are good products too, just not good enough to justify >> a downgrade from the better one ;-) > > > Totally agree, I just meant that puppet does have more mindshare these days > and you'll probably find more people familiar with it. We have used cfengine > for 10+ years, not that we haven't discovered flaws over time but I'm > certainly very happy with it and see no reason to change. We have had > student sysadmins come in, have to learn cfengine, they also look at puppet, > and comment that cfengine was a good choice. > > Just as we here still write most of our support scripts etc in perl, that is > also unfashionable now, doesn't mean it's not the best tool for the job (fx: > throws bomb and runs away... :-) > > Graham
Re: puppet
On Fri, Feb 22, 2013 at 11:39:58AM -0500, Paul Robert Marino wrote: > The only problem I ever had with cfengine is the documentation was > never all that great but it is stable and scales well. > That being said puppet is not perfect many of the stock recipes for it > you find on the web don't scale well and to get it to scale you really > need to be a ruby programer. My other issue with puppet is it doesn't > provide you with a great amount of control over the timing of the > deployment of changes unless you go to significant lengths. > Essentially its good for a "Agile development model" environment which > is popular with many web companies; however its a nightmare for > mission critical 24x7x365 environments which require changes to be > scheduled in advance. At the risk of continuing off-topic for the list... but it's a really interesting discussion... We ended up building a bunch of infrastructure around cfengine to help with this kind of thing. First step was getting the cfengine config into version control (svn, then git), which seems basic now, but I certainly wasn't doing that 10 years ago! Then one of our smart student sysadmins devised a way we could make development branches of the config, and tell specific machines which branch cfengine should use. That's been very useful for figuring out more complicated actions like setting up OSG nodes. Of course once you build this kind of infrastructure and have it working, you're reluctant to abandon it. Maybe there are tools which do all this for you now, that's why this is such a good thread. > These days I'm using Spacewalk for most of what I would have used > cfengine or puppet for in the past the only thing that it doesn't do > out of the box is make sure that particular services are running or > not running at boot, but there are a myriad of other simple ways to do > that which require very little work, and if I really wanted to I could > get spacewalk to do that as well via the soap APIs. Yes, spacewalk seems like it can do a lot (some of our neighbors here use it). We still have a somewhat multiplatform environment - SL, FreeBSD, a few lingering legacy systems still hanging on (tru64), so more generic tools are still important to us. Graham -- - Graham Allan - I.T. Manager School of Physics and Astronomy - University of Minnesota -
RE: puppet
If you have temporary staff, they would also be interested in having Puppet skills on their CVs this is from job adverts trends on indeed.com asking for particular skills in open posts. > -Original Message- > From: owner-scientific-linux-us...@listserv.fnal.gov > [mailto:owner-scientific- > linux-us...@listserv.fnal.gov] On Behalf Of Graham Allan > Sent: 22 February 2013 17:05 > To: Natxo Asenjo > Cc: SCIENTIFIC-LINUX-USERS@FNAL.GOV > Subject: Re: puppet > > On 2/21/2013 4:13 PM, Natxo Asenjo wrote: > > On Thu, Feb 21, 2013 at 9:38 PM, Graham Allan < > > <mailto:al...@physics.umn.edu> al...@physics.umn.edu> > wrote: > >> > >> Also cfengine, though that seems to be getting less fashionable... We > >> still use it, no compelling reasons to change so far! > > > > we take our decisions based on functionality, not fashion. > > > > Cfengine is just fine. Good performance, little dependencies, good > > security record (not unimportant for your infrastructure management > > tool and oh what a start of the year for ruby it was), and it has in > > place editing instead of requiring you to use yet another tool > > (augeas). > > > > But puppet/chef are good products too, just not good enough to justify > > a downgrade from the better one ;-) > > Totally agree, I just meant that puppet does have more mindshare these days > and you'll probably find more people familiar with it. We have used cfengine > for 10+ years, not that we haven't discovered flaws over time but I'm > certainly > very happy with it and see no reason to change. We have had student > sysadmins come in, have to learn cfengine, they also look at puppet, and > comment that cfengine was a good choice. > > Just as we here still write most of our support scripts etc in perl, that is > also > unfashionable now, doesn't mean it's not the best tool for the job (fx: > throws > bomb and runs away... :-) > > Graham <> smime.p7s Description: S/MIME cryptographic signature
Re: puppet
well considering that you might have some fun with my old mrtools project http://sourceforge.net/projects/mrtools/ P.S. I havens abandoned it I just haven't written a new version in a while because I keep tinkering with the design for the 2.x series which will primarily be written using OO Perl modules. On Fri, Feb 22, 2013 at 12:51 PM, Yasha Karant wrote: > We too used to use components written in perl under a distributed > environment. As this is a new installation, and as we need to find a more > maintainable and scalable solution, I posed the query for comments from > those with actual field experience. > > The fact that puppet does not seem to scale well is bothersome -- ruby is no > problem as various members of the group have (some) fluency in many > languages, including ruby, perl, python, java, and the incarnations of sh > (sh, bash, ksh, etc. -- with current emphasis upon bash). > > Our leaning now is to use cfengine. > > Yasha Karant > > > On 02/22/2013 08:39 AM, Paul Robert Marino wrote: >> >> The only problem I ever had with cfengine is the documentation was >> never all that great but it is stable and scales well. >> That being said puppet is not perfect many of the stock recipes for it >> you find on the web don't scale well and to get it to scale you really >> need to be a ruby programer. My other issue with puppet is it doesn't >> provide you with a great amount of control over the timing of the >> deployment of changes unless you go to significant lengths. >> Essentially its good for a "Agile development model" environment which >> is popular with many web companies; however its a nightmare for >> mission critical 24x7x365 environments which require changes to be >> scheduled in advance. >> >> These days I'm using Spacewalk for most of what I would have used >> cfengine or puppet for in the past the only thing that it doesn't do >> out of the box is make sure that particular services are running or >> not running at boot, but there are a myriad of other simple ways to do >> that which require very little work, and if I really wanted to I could >> get spacewalk to do that as well via the soap APIs. >> >> >> On Fri, Feb 22, 2013 at 11:04 AM, Graham Allan >> wrote: >>> >>> On 2/21/2013 4:13 PM, Natxo Asenjo wrote: >>>> >>>> >>>> On Thu, Feb 21, 2013 at 9:38 PM, Graham Allan >>>> wrote: >>>>> >>>>> >>>>> >>>>> Also cfengine, though that seems to be getting less fashionable... We >>>>> still use it, no compelling reasons to change so far! >>>> >>>> >>>> >>>> we take our decisions based on functionality, not fashion. >>>> >>>> Cfengine is just fine. Good performance, little dependencies, good >>>> security record (not unimportant for your infrastructure management >>>> tool and oh what a start of the year for ruby it was), and it has in >>>> place editing instead of requiring you to use yet another tool >>>> (augeas). >>>> >>>> But puppet/chef are good products too, just not good enough to justify >>>> a downgrade from the better one ;-) >>> >>> >>> >>> Totally agree, I just meant that puppet does have more mindshare these >>> days >>> and you'll probably find more people familiar with it. We have used >>> cfengine >>> for 10+ years, not that we haven't discovered flaws over time but I'm >>> certainly very happy with it and see no reason to change. We have had >>> student sysadmins come in, have to learn cfengine, they also look at >>> puppet, >>> and comment that cfengine was a good choice. >>> >>> Just as we here still write most of our support scripts etc in perl, that >>> is >>> also unfashionable now, doesn't mean it's not the best tool for the job >>> (fx: >>> throws bomb and runs away... :-) >>> >>> Graham
Re: puppet
2013/2/22 Yasha Karant > [...] > The fact that puppet does not seem to scale well is bothersome -- ruby is > no problem as various members of the group have (some) fluency in many > languages, including ruby, perl, python, java, and the incarnations of sh > (sh, bash, ksh, etc. -- with current emphasis upon bash). > [...] > Puppet does scale, even up to many 10k of servers, but you need more than one instance to serve this amount of servers and you need to optimize the configuration for performance (PuppetDB, Passenger, ...). But large scale installations in general are possible with Puppet and pretty sure, with others as well. Regards, Thomas -- Linux ... enjoy the ride!
RE: puppet
I'm not sure where the statement that Puppet does not scale well comes from... You do need to have enough puppet masters and architect it according to the best practises but the books tell you how to do this. Tim > -Original Message- > From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner-scientific- > linux-us...@listserv.fnal.gov] On Behalf Of Yasha Karant > Sent: 22 February 2013 18:52 > To: SCIENTIFIC-LINUX-USERS@FNAL.GOV > Subject: Re: puppet > > We too used to use components written in perl under a distributed > environment. As this is a new installation, and as we need to find a more > maintainable and scalable solution, I posed the query for comments from those > with actual field experience. > > The fact that puppet does not seem to scale well is bothersome -- ruby is no > problem as various members of the group have (some) fluency in many > languages, including ruby, perl, python, java, and the incarnations of sh (sh, > bash, ksh, etc. -- with current emphasis upon bash). > > Our leaning now is to use cfengine. > > Yasha Karant > > On 02/22/2013 08:39 AM, Paul Robert Marino wrote: > > The only problem I ever had with cfengine is the documentation was > > never all that great but it is stable and scales well. > > That being said puppet is not perfect many of the stock recipes for it > > you find on the web don't scale well and to get it to scale you really > > need to be a ruby programer. My other issue with puppet is it doesn't > > provide you with a great amount of control over the timing of the > > deployment of changes unless you go to significant lengths. > > Essentially its good for a "Agile development model" environment which > > is popular with many web companies; however its a nightmare for > > mission critical 24x7x365 environments which require changes to be > > scheduled in advance. > > > > These days I'm using Spacewalk for most of what I would have used > > cfengine or puppet for in the past the only thing that it doesn't do > > out of the box is make sure that particular services are running or > > not running at boot, but there are a myriad of other simple ways to do > > that which require very little work, and if I really wanted to I could > > get spacewalk to do that as well via the soap APIs. > > > > > > On Fri, Feb 22, 2013 at 11:04 AM, Graham Allan > wrote: > >> On 2/21/2013 4:13 PM, Natxo Asenjo wrote: > >>> > >>> On Thu, Feb 21, 2013 at 9:38 PM, Graham Allan > >>> > >>> wrote: > >>>> > >>>> > >>>> Also cfengine, though that seems to be getting less fashionable... > >>>> We still use it, no compelling reasons to change so far! > >>> > >>> > >>> we take our decisions based on functionality, not fashion. > >>> > >>> Cfengine is just fine. Good performance, little dependencies, good > >>> security record (not unimportant for your infrastructure management > >>> tool and oh what a start of the year for ruby it was), and it has in > >>> place editing instead of requiring you to use yet another tool > >>> (augeas). > >>> > >>> But puppet/chef are good products too, just not good enough to > >>> justify a downgrade from the better one ;-) > >> > >> > >> Totally agree, I just meant that puppet does have more mindshare > >> these days and you'll probably find more people familiar with it. We > >> have used cfengine for 10+ years, not that we haven't discovered > >> flaws over time but I'm certainly very happy with it and see no > >> reason to change. We have had student sysadmins come in, have to > >> learn cfengine, they also look at puppet, and comment that cfengine was a > good choice. > >> > >> Just as we here still write most of our support scripts etc in perl, > >> that is also unfashionable now, doesn't mean it's not the best tool for the job > (fx: > >> throws bomb and runs away... :-) > >> > >> Graham smime.p7s Description: S/MIME cryptographic signature
Re: puppet
We too used to use components written in perl under a distributed environment. As this is a new installation, and as we need to find a more maintainable and scalable solution, I posed the query for comments from those with actual field experience. The fact that puppet does not seem to scale well is bothersome -- ruby is no problem as various members of the group have (some) fluency in many languages, including ruby, perl, python, java, and the incarnations of sh (sh, bash, ksh, etc. -- with current emphasis upon bash). Our leaning now is to use cfengine. Yasha Karant On 02/22/2013 08:39 AM, Paul Robert Marino wrote: The only problem I ever had with cfengine is the documentation was never all that great but it is stable and scales well. That being said puppet is not perfect many of the stock recipes for it you find on the web don't scale well and to get it to scale you really need to be a ruby programer. My other issue with puppet is it doesn't provide you with a great amount of control over the timing of the deployment of changes unless you go to significant lengths. Essentially its good for a "Agile development model" environment which is popular with many web companies; however its a nightmare for mission critical 24x7x365 environments which require changes to be scheduled in advance. These days I'm using Spacewalk for most of what I would have used cfengine or puppet for in the past the only thing that it doesn't do out of the box is make sure that particular services are running or not running at boot, but there are a myriad of other simple ways to do that which require very little work, and if I really wanted to I could get spacewalk to do that as well via the soap APIs. On Fri, Feb 22, 2013 at 11:04 AM, Graham Allan wrote: On 2/21/2013 4:13 PM, Natxo Asenjo wrote: On Thu, Feb 21, 2013 at 9:38 PM, Graham Allan wrote: Also cfengine, though that seems to be getting less fashionable... We still use it, no compelling reasons to change so far! we take our decisions based on functionality, not fashion. Cfengine is just fine. Good performance, little dependencies, good security record (not unimportant for your infrastructure management tool and oh what a start of the year for ruby it was), and it has in place editing instead of requiring you to use yet another tool (augeas). But puppet/chef are good products too, just not good enough to justify a downgrade from the better one ;-) Totally agree, I just meant that puppet does have more mindshare these days and you'll probably find more people familiar with it. We have used cfengine for 10+ years, not that we haven't discovered flaws over time but I'm certainly very happy with it and see no reason to change. We have had student sysadmins come in, have to learn cfengine, they also look at puppet, and comment that cfengine was a good choice. Just as we here still write most of our support scripts etc in perl, that is also unfashionable now, doesn't mean it's not the best tool for the job (fx: throws bomb and runs away... :-) Graham
Re: puppet
The only problem I ever had with cfengine is the documentation was never all that great but it is stable and scales well. That being said puppet is not perfect many of the stock recipes for it you find on the web don't scale well and to get it to scale you really need to be a ruby programer. My other issue with puppet is it doesn't provide you with a great amount of control over the timing of the deployment of changes unless you go to significant lengths. Essentially its good for a "Agile development model" environment which is popular with many web companies; however its a nightmare for mission critical 24x7x365 environments which require changes to be scheduled in advance. These days I'm using Spacewalk for most of what I would have used cfengine or puppet for in the past the only thing that it doesn't do out of the box is make sure that particular services are running or not running at boot, but there are a myriad of other simple ways to do that which require very little work, and if I really wanted to I could get spacewalk to do that as well via the soap APIs. On Fri, Feb 22, 2013 at 11:04 AM, Graham Allan wrote: > On 2/21/2013 4:13 PM, Natxo Asenjo wrote: >> >> On Thu, Feb 21, 2013 at 9:38 PM, Graham Allan >> wrote: >>> >>> >>> Also cfengine, though that seems to be getting less fashionable... We >>> still use it, no compelling reasons to change so far! >> >> >> we take our decisions based on functionality, not fashion. >> >> Cfengine is just fine. Good performance, little dependencies, good >> security record (not unimportant for your infrastructure management >> tool and oh what a start of the year for ruby it was), and it has in >> place editing instead of requiring you to use yet another tool >> (augeas). >> >> But puppet/chef are good products too, just not good enough to justify >> a downgrade from the better one ;-) > > > Totally agree, I just meant that puppet does have more mindshare these days > and you'll probably find more people familiar with it. We have used cfengine > for 10+ years, not that we haven't discovered flaws over time but I'm > certainly very happy with it and see no reason to change. We have had > student sysadmins come in, have to learn cfengine, they also look at puppet, > and comment that cfengine was a good choice. > > Just as we here still write most of our support scripts etc in perl, that is > also unfashionable now, doesn't mean it's not the best tool for the job (fx: > throws bomb and runs away... :-) > > Graham
Perl config scripts, was Re: puppet
[ Changing thread title to handle Perls of wisdom] On Fri, Feb 22, 2013 at 11:04 AM, Graham Allan wrote: > Just as we here still write most of our support scripts etc in perl, that is > also unfashionable now, doesn't mean it's not the best tool for the job (fx: > throws bomb and runs away... :-) > > Graham As long as you package the modules, you can get away with this. One of the painful difficulties comes when people put "cpan build Foo::bar" for the Foo:::Bar module to enable features on their deployed systems, built right into their config scripts or testing tools or instlalers, and wind up displacing system versions of core utilities. This can, and has, included accidentally replacing Perl itself at various times to get various updated modules. Fortunately, for SL and other upstream vendor based modules, it's often possible to find them in 3rdparty repositories, especially loo, in Fedora for backporting, or to use tools like "cpan2rpm" or "cpanspec" to build RPM's for them which you can deploy in an internal yum repository or for direct installation via cfengine or puppet. similar techniques work well for PHP and Ruby modules as well. I actually publish a whole stack of these over at https://github.com/nkadel/. And i'm happy to show other people how to set up build environments for that.
Re: puppet
On 2/21/2013 4:13 PM, Natxo Asenjo wrote: On Thu, Feb 21, 2013 at 9:38 PM, Graham Allan wrote: Also cfengine, though that seems to be getting less fashionable... We still use it, no compelling reasons to change so far! we take our decisions based on functionality, not fashion. Cfengine is just fine. Good performance, little dependencies, good security record (not unimportant for your infrastructure management tool and oh what a start of the year for ruby it was), and it has in place editing instead of requiring you to use yet another tool (augeas). But puppet/chef are good products too, just not good enough to justify a downgrade from the better one ;-) Totally agree, I just meant that puppet does have more mindshare these days and you'll probably find more people familiar with it. We have used cfengine for 10+ years, not that we haven't discovered flaws over time but I'm certainly very happy with it and see no reason to change. We have had student sysadmins come in, have to learn cfengine, they also look at puppet, and comment that cfengine was a good choice. Just as we here still write most of our support scripts etc in perl, that is also unfashionable now, doesn't mean it's not the best tool for the job (fx: throws bomb and runs away... :-) Graham
Re: puppet
You may add Quattor to the list of not so fashionable but very powerful configuration tools! Check http://quattor.org. Cheers, Michel --On jeudi 21 février 2013 23:13 +0100 Natxo Asenjo wrote: On Thu, Feb 21, 2013 at 9:38 PM, Graham Allan wrote: On Thu, Feb 21, 2013 at 02:27:07PM -0500, Jamie Duncan wrote: pro - powerful and well-supported con - you have to learn a new syntax alternative - bcfg2 Also cfengine, though that seems to be getting less fashionable... We still use it, no compelling reasons to change so far! we take our decisions based on functionality, not fashion. Cfengine is just fine. Good performance, little dependencies, good security record (not unimportant for your infrastructure management tool and oh what a start of the year for ruby it was), and it has in place editing instead of requiring you to use yet another tool (augeas). But puppet/chef are good products too, just not good enough to justify a downgrade from the better one ;-) -- natxo * * Michel Jouvin Email : jou...@lal.in2p3.fr * * LAL / CNRSTel : +33 1 64468932* * B.P. 34 Fax : +33 1 69079404* * 91898 Orsay Cedex * * France* *
Re: puppet
On Thu, Feb 21, 2013 at 9:38 PM, Graham Allan wrote: > On Thu, Feb 21, 2013 at 02:27:07PM -0500, Jamie Duncan wrote: >> pro - powerful and well-supported >> con - you have to learn a new syntax >> >> alternative - bcfg2 > > Also cfengine, though that seems to be getting less fashionable... We > still use it, no compelling reasons to change so far! we take our decisions based on functionality, not fashion. Cfengine is just fine. Good performance, little dependencies, good security record (not unimportant for your infrastructure management tool and oh what a start of the year for ruby it was), and it has in place editing instead of requiring you to use yet another tool (augeas). But puppet/chef are good products too, just not good enough to justify a downgrade from the better one ;-) -- natxo
Re: puppet
On 02/21/2013 12:23 PM, Yasha Karant wrote: Does anyone have experience with puppet from URL: https://puppetlabs.com/ ? If so, positive and/or negative observations are requested, as well as practical alternatives. Yasha Karant We've been using it for a while and have been fairly happy with it. As others have said, it is a big community and lots of support. Our issue in a mixed environment is that the puppet master must always be a newer version than the agents. This has been tricky with maintaining a mix of EL and Fedora clients. Keeping in sync with ruby versions has been tricky too for the Fedora and EPEL puppet packages. I've wanted to look at ansible for a while, which is agentless (via ssh). -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: puppet
On Thu, Feb 21, 2013 at 2:23 PM, Yasha Karant wrote: > Does anyone have experience with puppet from URL: > > https://puppetlabs.com/ > > ? > > If so, positive and/or negative observations are requested, as well as > practical alternatives. > > Yasha Karant Switching is expensive. It's Ruby based, so iif you haven't mastered Ruby your ability to write new modules is limited. And it requires a complex backend database: anytime you introduce a database in a critical path, you have to factor in the reliability and support of the database itself. The result is the last two times I evaluated it I rejected as too complicated, and too much work, to replace the existing and admittedly complex hand-written infrastructure or separate cfengine or Bladelogic management tools in place. It has a good reputation, and a lot of users, so new modules to do things are often available directly rather than requiring personal authorship.
Re: puppet
We use it for our Scientific Linux systems at IoraHealth. We use Puppet in its "standalone" mode so we don't need the added infrastructure for a Puppet Master -- something like the strategy here: http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control (And we have just started provisioning developer machines -- on OS/X -- with GitHub's Boxen, which is built on Puppet.) I am glad to hear that other people are updating modules for Scientific Linux. We found that it was fairly difficult to use off-the-shelf modules, and wrote a lot of our own. On Thu, Feb 21, 2013 at 2:43 PM, aurfalien wrote: > Many in the VFX industry use it as well. > > Pretty solid. > > Was using CacheFS in Irix many moons ago and then various manually > maintained kick starts/rysncs but all in all, Puppet is pretty shweet. > > - aurf > > > On Feb 21, 2013, at 12:38 PM, Graham Allan wrote: > > > On Thu, Feb 21, 2013 at 02:27:07PM -0500, Jamie Duncan wrote: > >> pro - powerful and well-supported > >> con - you have to learn a new syntax > >> > >> alternative - bcfg2 > > > > Also cfengine, though that seems to be getting less fashionable... We > > still use it, no compelling reasons to change so far! > > > > G. > > -- > > - > > Graham Allan - I.T. Manager > > School of Physics and Astronomy - University of Minnesota > > - >
Re: puppet
Many in the VFX industry use it as well. Pretty solid. Was using CacheFS in Irix many moons ago and then various manually maintained kick starts/rysncs but all in all, Puppet is pretty shweet. - aurf On Feb 21, 2013, at 12:38 PM, Graham Allan wrote: > On Thu, Feb 21, 2013 at 02:27:07PM -0500, Jamie Duncan wrote: >> pro - powerful and well-supported >> con - you have to learn a new syntax >> >> alternative - bcfg2 > > Also cfengine, though that seems to be getting less fashionable... We > still use it, no compelling reasons to change so far! > > G. > -- > - > Graham Allan - I.T. Manager > School of Physics and Astronomy - University of Minnesota > -
Re: puppet
On Thu, Feb 21, 2013 at 02:27:07PM -0500, Jamie Duncan wrote: > pro - powerful and well-supported > con - you have to learn a new syntax > > alternative - bcfg2 Also cfengine, though that seems to be getting less fashionable... We still use it, no compelling reasons to change so far! G. -- - Graham Allan - I.T. Manager School of Physics and Astronomy - University of Minnesota -
Re: puppet
We (another group at Fermilab) have used Puppet for a couple of years now to manage a few thousand systems, with good results. As Steve and Jamie both noted, it's essentially a new language to learn, though a fairly simple and well-behaved one. There are many user-contributed modules available, etc. We switched from cfengine, which is a viable alternative but has some limitations that we wanted to get past. Glenn At 1:29pm on Thu, 21 Feb 2013, Steven Timm wrote: Large puppet community at Fermilab--I started using it a few months ago and have been able to get productive and do a lot of things with it very quickly. Many of its config files are written in a Ruby-like syntax so Ruby training pays off with faster learning time. Steve Timm On Thu, 21 Feb 2013, Yasha Karant wrote: Does anyone have experience with puppet from URL: https://puppetlabs.com/ ? If so, positive and/or negative observations are requested, as well as practical alternatives. Yasha Karant -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Computing Division, Scientific Computing Facilities, Grid Facilities Department, FermiGrid Services Group, Group Leader. Lead of FermiCloud project.
RE: puppet
CERN are also using puppet as part of our tools transformation to replace Quattor (Ben Jones's video from last PuppetConf at http://www.youtube.com/watch?v=ehVMxbJdld8 and the CHEP paper at http://cern.ch/go/N8wp) Our configurations are at https://github.com/cernops. We're also working through many of the standard PuppetForge modules to make sure they understand Scientific Linux (as well as RedHat) as an OS family. Puppet is used at BNL, IN2P3, LBNL. There are a number of other labs looking at it. Tim > -Original Message- > From: owner-scientific-linux-us...@listserv.fnal.gov > [mailto:owner-scientific- > linux-us...@listserv.fnal.gov] On Behalf Of James M Pulver > Sent: 21 February 2013 20:36 > To: owner-scientific-linux-us...@listserv.fnal.gov > Cc: scientific-linux-us...@listserv.fnal.gov > Subject: RE: puppet > > We're just spinning up Puppet with The Foreman frontend, and it looks quite > powerful and useful. It's beneficial in that the FLOSS version also has well > behaved Windows clients... > > -- > James Pulver > LEPP Computer Group > Cornell University > > > -Original Message- > From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner- > scientific-linux-us...@listserv.fnal.gov] On Behalf Of Steven Timm > Sent: Thursday, February 21, 2013 2:30 PM > To: Yasha Karant > Cc: scientific-linux-us...@listserv.fnal.gov > Subject: Re: puppet > > Large puppet community at Fermilab--I started using it a few months ago and > have been able to get productive and do a lot of things with it very > quickly. > Many of its config files are written in a Ruby-like syntax so Ruby training > pays > off with faster learning time. > > Steve Timm > > > On Thu, 21 Feb 2013, Yasha Karant wrote: > > > Does anyone have experience with puppet from URL: > > > > https://puppetlabs.com/ > > > > ? > > > > If so, positive and/or negative observations are requested, as well as > > practical alternatives. > > > > Yasha Karant > > > > -- > Steven C. Timm, Ph.D (630) 840-8525 > t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Computing Division, > Scientific Computing Facilities, Grid Facilities Department, FermiGrid > Services > Group, Group Leader. > Lead of FermiCloud project. smime.p7s Description: S/MIME cryptographic signature
Re: puppet
2013/2/21 Yasha Karant > Does anyone have experience with puppet from URL: > https://puppetlabs.com/ > ? > If so, positive and/or negative observations are requested, as well as > practical alternatives. > [...] > I use puppet since round about three years with round about 70 clients. As an ENC I use foreman. Puppet is very powerful, there is a big community with lot of free resources around and several big companies use Puppet. The only negative thing I discovered so far is the performance. It's getting better since 3.x and PuppetDB but still an issue compared to other products. But fortunately, performance is not the number one topic in this area ;). -- Linux ... enjoy the ride!
RE: puppet
We're just spinning up Puppet with The Foreman frontend, and it looks quite powerful and useful. It's beneficial in that the FLOSS version also has well behaved Windows clients... -- James Pulver LEPP Computer Group Cornell University -Original Message- From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Steven Timm Sent: Thursday, February 21, 2013 2:30 PM To: Yasha Karant Cc: scientific-linux-us...@listserv.fnal.gov Subject: Re: puppet Large puppet community at Fermilab--I started using it a few months ago and have been able to get productive and do a lot of things with it very quickly. Many of its config files are written in a Ruby-like syntax so Ruby training pays off with faster learning time. Steve Timm On Thu, 21 Feb 2013, Yasha Karant wrote: > Does anyone have experience with puppet from URL: > > https://puppetlabs.com/ > > ? > > If so, positive and/or negative observations are requested, as well as > practical alternatives. > > Yasha Karant > -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Computing Division, Scientific Computing Facilities, Grid Facilities Department, FermiGrid Services Group, Group Leader. Lead of FermiCloud project.
Re: puppet
Large puppet community at Fermilab--I started using it a few months ago and have been able to get productive and do a lot of things with it very quickly. Many of its config files are written in a Ruby-like syntax so Ruby training pays off with faster learning time. Steve Timm On Thu, 21 Feb 2013, Yasha Karant wrote: Does anyone have experience with puppet from URL: https://puppetlabs.com/ ? If so, positive and/or negative observations are requested, as well as practical alternatives. Yasha Karant -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Computing Division, Scientific Computing Facilities, Grid Facilities Department, FermiGrid Services Group, Group Leader. Lead of FermiCloud project.
Re: puppet
pro - powerful and well-supported con - you have to learn a new syntax alternative - bcfg2 On Thu, Feb 21, 2013 at 2:23 PM, Yasha Karant wrote: > Does anyone have experience with puppet from URL: > > https://puppetlabs.com/ > > ? > > If so, positive and/or negative observations are requested, as well as > practical alternatives. > > Yasha Karant > -- Thanks, Jamie Duncan @jamieeduncan
puppet
Does anyone have experience with puppet from URL: https://puppetlabs.com/ ? If so, positive and/or negative observations are requested, as well as practical alternatives. Yasha Karant
