dayglojesus
commented
9 years ago There aren't a lot of choices when it comes to executing conditional resource application in Puppet. The constructs and language features are there, but they're not flexible enough to deal with dynamic environments.
Functions are handy, but they suck if you need information specific to the client because they're executed by the Puppet Master. This makes sense because it's the Puppet Master that should be determining state, not the client. Still, this one-way street can be aggravating when your client doesn't live at a fixed address. If they ride around town in a Winnebago, and you never know what street they're going to be on, you are basically f'd.
Apart from building conditional logic into the type/provider, there's really only one choice...
Facter.
Ginja
Binding to AD using a profile is great, except for one thing...
When you change the content of a profile, it's an all or nothing operation. If you need to modify one of the plugin settings after you've deployed the profile, the entire profile will be removed and reinstalled.
However, if your AD is not available when this happens, you will wind up with cascading Puppet resource failures. Fun!
Example:
As a workaround, create a new class param that will force a check the availability of the specified Active Directory domain before attempting any operations.