Puppet users - Aug 2013 - Benefits of retrofitting Puppet to a legacy fleet

Hi all,

I am going to have a meeting to sell the idea of retrofitting Puppet to a 
fleet of already-built legacy Unix systems to a skeptical management (as 
opposed to only using it to build new linux systems, where I don''t need
to
sell the idea).

Here, "legacy Unix" means AIX, Solaris, HP-UX, and various versions of
Linux.  Much of the work is already done as far as deployment to these 
platforms is concerned, so the difficulty of compiling Ruby, etc, on 
Platform X version Y doesn''t need to be considered.

I see the following benefits:

1)  Having facter on every computer in the company is good.
2)  Having MCollective replace your for loops everywhere is good.
3)  Being able to standardise configuration of some simple services, e.g. 
NTP, root''s profile, etc., is better than not having standardised these
services.
4)  Any services that you can migrate into Puppet become visible in Puppet 
manifests, which is always better than documentation in a Wiki, which may 
or may not be up to date.

Being more ambitious, I am thinking that with MCollective, it might be 
possible to use Puppet to install patches etc. on legacy systems.  Maybe 
even possible, with a lot of effort, to fully automate the patching of 
everything, and have the change management system automatically updated as 
well.

Any/all ideas/criticisms are appreciated.  I have one week to write the 
proposal.

Thanks in advance.
Alex

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

On Fri, Aug 2, 2013 at 4:26 AM, Alex Harvey <alexharv074@gmail.com> wrote:
> Hi all,
>
> I am going to have a meeting to sell the idea of retrofitting Puppet to a
> fleet of already-built legacy Unix systems to a skeptical management (as
> opposed to only using it to build new linux systems, where I don''t
need to
> sell the idea).
>
> Here, "legacy Unix" means AIX, Solaris, HP-UX, and various
versions of
> Linux.  Much of the work is already done as far as deployment to these
> platforms is concerned, so the difficulty of compiling Ruby, etc, on
> Platform X version Y doesn''t need to be considered.
>
> I see the following benefits:
>
> 1)  Having facter on every computer in the company is good.
> 2)  Having MCollective replace your for loops everywhere is good.
> 3)  Being able to standardise configuration of some simple services, e.g.
> NTP, root''s profile, etc., is better than not having standardised
these
> services.
> 4)  Any services that you can migrate into Puppet become visible in Puppet
> manifests, which is always better than documentation in a Wiki, which may
> or may not be up to date.
>
> Being more ambitious, I am thinking that with MCollective, it might be
> possible to use Puppet to install patches etc. on legacy systems.  Maybe
> even possible, with a lot of effort, to fully automate the patching of
> everything, and have the change management system automatically updated as
> well.
>
> Any/all ideas/criticisms are appreciated.  I have one week to write the
> proposal.
>
All of those points seem reasonable to me! If it wasn''t for HP-UX I
would
suggest
P<http://docs.puppetlabs.com/pe/latest/install_system_requirements.html>uppet
Enterprise as they have pre-compiled everything for AIX, Solaris, and so
on.  They might be able to package up for HP-UX if the number of nodes is
big enough. :)

At a previous job I used mcollective for patch management and sort of
change control, so these things are definitely possible.  We had a modified
package agent that could take various options to generate reports in
different ways (mostly CSV, we weren''t fancy) and could then be used to
do
rolling patch upgrades across various clusters.  For change management we
were more focused on tying specific git commits to triggered puppet runs so
that we could verify that X change made it out to all the machines, so what
you''re looking to do sounds completely reasonable.

I found when writing proposals for Puppet that focusing on point 4 in your
above list was by far the most persuasive.  A service fully converted to
Puppet is by definition documented and repeatable and in a large
corporation that''s probably more important than any other point you can
raise in favor of puppet.  The number of times I''ve had to deal with a
critical failure of an undocumented and unknown system or find a way to
migrate an old setup to a new operating system with no information..

Good luck!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.