The `config_get_lookup` and `config_get` sources lack flexibility.
It's not easy to query several pillars and/or grains keys with the
actual system. And the query method is forced to `config.get` without
being configurable by the user.
We define a mechanism to select `map.jinja` sources with similar
notation as the salt targeting system.
The `map.jinja` file uses several sources where to lookup parameter
values. The list of sources can be modified by two files:
1. a global salt://parameters/map_jinja.yaml
2. a per formula salt://{{ tplroot }}/parameters/map_jinja.yaml.
Each source definition has the form `<TYPE>:<OPTION>@<KEY>` where
`<TYPE>` can be one of:
- `Y` to load values from YAML files, this is the default when no type
is defined
- `C` to lookup values with `config.get`
- `G` to lookup values with `grains.get`
- `I` to lookup values with `pillar.get`
The YAML type option can define the query method to lookup the key
value to build the file name:
- `C` to query with `config.get`, this is the default when to query
method is defined
- `G` to query with `grains.get`
- `I` to query with `pillar.get`
The `C`, `G` or `I` types can define the `SUB` option to store values
in the sub key `mapdata.<key>` instead of directly in `mapdata`.
Finally, the `<KEY>` describe what to lookup to either build the YAML
filename or gather values using one of the query method.
BREAKING CHANGE: the configuration `map_jinja:sources` is only
configurable with `salt://parameters/map_jinja.yaml`
and `salt://{{ tplroot }}/parameters/map_jinja.yaml`
BREAKING CHANGE: the `map_jinja:config_get_roots` is replaced by
compound like `map_jinja:sources`
BREAKING CHANGE: the two `config_get_lookup` and `config_get` are
replaced by `C@<tplroot>:lookup` and `C@<tplroot>`
sources
The debug output of test jobs don't show the use of TOFS as it should
and the pillar.example show that `tofs` is under `mine_functions`
instead of `openssh`.
* pillar.example: move `tofs` under `openssh`.
* test/salt/pillar/default.sls: ditoo.
We avoid compatibility break with user pillars by looking up
configuration values using `config.get` in configurable roots.
We provide a new parameter `map_jinja:config_get_roots` in the formula
`parameters/defaults.yaml`to retrives values not only from
`tplroot=openssh` but from `sshd_config` and `ssh_config` too.
We need to update the `_mapdata` reference files to include the new
`map_jinja:config_get_roots`.
The `map.jinja` now exports a single variable called `mapdata`.
We extract the `openssh`, `sshd_config` and `ssh_config` from it to
minimize the changes to `.sls` files.
We store validated `map.jinja` dump under the profile `files`
directory to access them with `inspec.profile.file('filename')` to
validate the content of the generated mapdata file.
The YAML files contain a value specific to each minion, its hostname,
so we use string format to expand `%{hostname}`.
The `default` inspec profile need to depends on `share` to access the
`system` and `salt_minion` libraries.
The `system.hostname` return the result of either `hostname -s` or
`hostnamectl --static` depending of the availability of each command.
The `system.platform` return a hash with tweaked `inspec.platform`
values:
- `system.platform[:family]` provides a family name for Arch
- `system.platform[:name]` modify `amazon` to `amazonlinux`
- `system.platform[:release]` tweak for Arch and Amazon Linux:
- `Arch` is always `base-later`
- `Amazon Linux` release `2018` became `1`
- `system.platform[:finger]` is just the concatenation of the name and
the first release number (except for Ubuntu which gives `20.04` for
example)
It apprears that the
`if not (omit_ip_address is sameas true or host in omit_ip_address)`
always returns `True` on older Jinja platforms:
- default-ubuntu-1604-3000-3-py2
- default-ubuntu-1604-2019-2-py3
- default-amazonlinux-1-2019-2-py2
Each part of the `or` conditional need to be surrounded by parenthesis.
