Rules for profile classes

There are rules for writing profile classes.

• Make sure you can safely include any profile multiple times — don't use resource-like declarations on them.
• Profiles can include other profiles.
• Profiles own all the class parameters for their component classes. If the profile omits one, that means you definitely want the default value; the component class shouldn't use a value from Hiera data. If you need to set a class parameter that was omitted previously, refactor the profile.
• There are three ways a profile can get the information it needs to configure component classes:
  • If your business always uses the same value for a given parameter, hardcode it.
  • If you can't hardcode it, try to compute it based on information you already have.
  • Finally, if you can't compute it, look it up in your data. To reduce lookups, identify cases where multiple parameters can be derived from the answer to a single question.

  This is a game of trade-offs. Hardcoded parameters are the easiest to read, and also the least flexible. Putting values in your Hiera data is very flexible, but can be very difficult to read: you might have to look through a lot of files (or run a lot of lookup commands) to see what the profile is actually doing. Using conditional logic to derive a value is a middle-ground. Aim for the most readable option you can get away with.