SCIENTIFIC-LINUX-USERS Archives

February 2013

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Tim Bell <[log in to unmask]>
Reply To:
Date:
Fri, 22 Feb 2013 17:54:59 +0000
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (3786 bytes) , smime.p7s (5 kB)

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: [log in to unmask]
[mailto:owner-scientific-
> [log in to unmask]] On Behalf Of Yasha Karant
> Sent: 22 February 2013 18:52
> To: [log in to unmask]
> 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 <[log in to unmask]>
> wrote:
> >> On 2/21/2013 4:13 PM, Natxo Asenjo wrote:
> >>>
> >>> On Thu, Feb 21, 2013 at 9:38 PM, Graham Allan
> >>> <[log in to unmask]>
> >>> 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


ATOM RSS1 RSS2