When running a pdk new module or pdk convert the current pdk-template adds in a hiera.yaml and common.yaml
To clarify, pdk adds a default hiera.yaml like:
--- |
version: 5 |
|
defaults: # Used for any hierarchy level that omits these keys. |
datadir: data # This path is relative to hiera.yaml's directory. |
data_hash: yaml_data # Use the built-in YAML backend. |
|
hierarchy: |
- name: "osfamily/major release" |
paths: |
- "os/%{facts.os.family}/%{facts.os.release.major}.yaml" |
# Used for Solaris |
- "os/%{facts.os.family}/%{facts.kernelrelease}.yaml" |
# Used to distinguish between Debian and Ubuntu |
- "os/%{facts.os.name}/%{facts.os.release.major}.yaml" |
- name: "osfamily" |
paths: |
- "os/%{facts.os.family}.yaml" |
- "os/%{facts.os.name}.yaml" |
- name: 'common' |
path: 'common.yaml'
|
so that modules are more "self documenting" and follow best practices. The pdk also adds an empty common.yaml, and it's that empty file that causes problems, since the yaml_data and eyaml_lookup_key functions require the file to contain a valid yaml *hash*. So while an empty file is valid yaml (it's the yaml scalar null), it doesn't contain a hash. We could make the functions more lenient, but I think that's going in the wrong direction. The pdk could just as easily add a "common" section that is commented out, or it could create a common.yaml containing a empty hash:
In the PDK ticket there is conversation about common.yaml adding additional lookups, so the former may be better. I'm inclined to close this as won't fix, thoughts Maggie Dreyer, Justin Stoller, Patrick Carlisle? |