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:
Paul Robert Marino <[log in to unmask]>
Reply To:
Paul Robert Marino <[log in to unmask]>
Date:
Fri, 22 Feb 2013 12:59:22 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (92 lines)
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 <[log in to unmask]> 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 <[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