Rules for 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 will always use 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.