On Fri, Aug 2, 2013 at 4:26 AM, Alex Harvey <alexharv...@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+unsubscr...@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.
