By now in your Puppet career, you've almost certainly been exposed to the phrases declarative state or state modeling. You may even have a pretty good idea of what the words mean. But how in the dickens do they relate to configuration management? The confusion only makes sense. We've been writing shell scripts to provision, configure, and even boot our computer systems for forty years. It's going to take a mighty strong argument to change that habit now.
Something that's been missing in my training classes for a while is a quantitative method for monitoring how well the class was keeping up. Instead, we relied on the ability of each instructor to effectively read the class and adjust pace appropriately. This does work, but it's less consistent than I'd like and it doesn't give me the ability to systematically gather metrics about the knowledge retention of the different training sections.
Clearly, I needed something better.
One of the more common questions I'm asked on #puppet is how to use existing state when applying configuration to a node. For example, "how can I tell when mysql is installed, so I can add a firewall rule for it?" In this post, I'm going to talk a little bit about why I think there's such a draw to this approach, then I'll explain why it's universally such a bad idea, and then I'll talk about better ways of accomplishing the same goals.
Puppet has this real neat concept of an external node classifier (ENC) that lets you define your nodes in some way that's not Puppet. If you have your nodes stored in anything from an LDAP database to even an Excel spreadsheet and you can write a script to connect to your datasource, then Puppet can call it to create its node definitions as it runs.