Public
Authored by Shawn Kwang

Rules for profile classes

The rules for profile classes

  1. Make sure you can safely include any profile multiple times — don’t use resource-like declarations on them.
  2. Profiles can include other profiles.
  3. 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.
  4. 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.

Edited
3 Bytes
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment