[CentOS] Spacewalk or Puppet?

[Karanbir Singh]

On 11/04/2009 04:35 PM, Les Mikesell wrote:
> What good is a configuration tool if it can't handle a change in NIC
> setup?  That's really about the only thing that is enough trouble to do
> manually that it is worth more automation than a shell loop of ssh commands.

I am not sure how you got from one place to another. Essentially any 
config tool is able to handle network setups, including stuff like 
bonding and HA. Think of it like this - if you can do it by hand, you 
can plumb in the knowledge the system needs to make those decisions for you.

> Exactly - and remote 'hands on' support generally won't know which NIC
> is which, making this fairly problematic.  And you can't just clone
> setups because the copies won't work with different MAC addresses.

I personally think that cloning is for people who dont know what they 
are doing. Bare metal install and provision into a role with even a 
moderately usable app deployment strategy, cap'd with a monitoring 
system that actually know what it needs to do - will easily be more 
friendly than any form of cloning.

> I'm not sure I agree with that.  I really do want to know about
> platform/state history even if I can't roll it back.

well, most people replace or upgrade the platform ( hardware ) when 
things break, so rolling back is sort of academic in this sense. You are 
much better off storing platform inventory in something like ocs / glpi 
/ spacewalk ( or even doing things like getting sosreport to give you 
the right foo, checking that into a local vcs - so you can 'track' a 
system's evolution )

 >  For example, if
> someone changes the duplex setting on a NIC to match a switch I'd like
> to have the change recorded - and a way to look at how that machine is
> different from both the way it was at some other time and from other
> similar machines.

how do you mean 'changes' ? I highly recommend there be no way for 
people to get onto the machine unless in an emergency. So no ssh as an 
example. That sort of ensures that policy changes like this, need to go 
via the management system - leaving you a nice audit trail.

Addition of a 'SSH box', needing people to contribute $5 everytime they 
get onto ssh, also helps get people into the right mindset :)

> Also, we almost never roll out a change across all machines in a group
> at the same time but instead closely schedule individual machines or
> small sets.

puppet, atleast, makes this sort of a thing trivial - since you can 
setup environments, and then nominate machines to join different 
environments on demand. It also make it possible for one to have 
code-like release and deployment cycles.

You could potentially even have various test and/or wrap some of the 
policy in tests with rollback capabilities ( I tend to do that for my 
ssh and puppet configs - configs for puppet itself that is ).

-- 
Karanbir Singh
London, UK        | http://www.karan.org/ | twitter.com/kbsingh
ICQ: 2522219      | Yahoo IM: z00dax      | Gtalk: z00dax
GnuPG Key : http://www.karan.org/publickey.asc