config mgmt - what we use from those systems
Hi,
I've complained often about my consternation with how we have puppet
used/deployed. In working on a few things this week I started thinking
a bit more about what it is we're doing with our config mgmt and what
should change. I've also been sending in some patches to another
project that is, ultimately, about instance deployment/command and
control. (https://github.com/ansible/ansible)
What I'm not interested in is talking about tools or projects, here.
I'm curious about what it is we require from config mgmt and what it is
we want from config mgmt.
Things I require/want:
- file replacement on change and notification of those changes
- pkg installation/removal
- service enable/disable/start/stop
- service/process state control
- variable replacement in files and/or in commands. (maybe this means
templating, maybe it doesn't)
- some sort of conditionalizing (if rhel5 do X) so you do not have 20
different copies of the same thing just for fun
- file replacement that includes cascading through a series of files
based on variables: [ filename.$fqdn, filename.$hostname,
filename.$datacenter, $filename.$group, $filename ]
From my perspective what we USE in fedora infrastructure is more or
less:
- config-mgmt as a way to configure a system and get it to its
normal-runtime state
- config-mgmt as a systems-maintenance tool - both to keep things
running which occasionally fall over and to make sure that no one
inadvertently changes a running system and doesn't commit it to be a
persistent change between system reinstalls.
We run things like:
- we have a new, basic system, please make it into a $blah_type system
- be that a webserver, builder, db server, whatever.
So I'd like to hear what other people think about what we use and how
we use it.
end note:
Something kevin said in the meeting today made sense to me. Perhaps we
should take our server configuration and (independent of any particular
config mgmt system) try to describe the set of steps necessary to go
from a new instance running el6 @core to a functional server of a
specific type.. I suspect if we wrote it all out in a note for any
system we'll find that tracking back the set of changes in our puppet
configs will be... challenging.
-sv