config mgmt - what we use from those systems

[seth vidal]

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