openssh-formula/openssh/map.jinja

184 lines
6.1 KiB
Plaintext
Raw Normal View History

# -*- coding: utf-8 -*-
# vim: ft=jinja
{#- Get the `tplroot` from `tpldir` #}
{%- set tplroot = tpldir.split("/")[0] %}
{%- from tplroot ~ "/libmatchers.jinja" import parse_matchers, query_map %}
{%- from tplroot ~ "/libmapstack.jinja" import mapstack %}
{#- Where to lookup parameters source files #}
{%- set map_sources_dir = tplroot ~ "/parameters" %}
{#- List of sources to lookup for parameters #}
{#- Fallback to previously used grains plus minion `id` #}
{%- set map_sources = [
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
"Y:G@osarch",
"Y:G@os_family",
"Y:G@os",
"Y:G@osfinger",
"C@" ~ tplroot ~ ":lookup",
"C@" ~ tplroot,
"Y:G@id",
] %}
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
{#- Allow centralised map.jinja configuration #}
{%- set _global_param_filename = "parameters/map_jinja.yaml" %}
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
{#- Allow per formula map.jinja configuration #}
{%- set _formula_param_filename = map_sources_dir ~ "/map_jinja.yaml" %}
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
{%- set _map_settings = mapstack(
files=[_global_param_filename, _formula_param_filename],
defaults={
"values": {"sources": map_sources}
},
log_prefix="map.jinja configuration: ",
)
| load_yaml %}
{%- set map_sources = _map_settings | traverse("values:sources") %}
{%- do salt["log.debug"](
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
"map.jinja: load parameters from sources:\n"
~ map_sources
| yaml(False)
) %}
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
{#- Load formula defaults values #}
{%- set _defaults_filename = map_sources_dir ~ "/defaults.yaml" %}
{%- do salt["log.debug"](
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
"map.jinja: load per formula default values from "
~ _defaults_filename
) %}
{%- load_yaml as default_settings %}
{%- include _defaults_filename ignore missing %}
{%- endload %}
{%- if not default_settings %}
{%- set default_settings = {'values': {} } %}
{%- endif %}
{#- Make sure to track `map.jinja` configuration with `_mapdata` #}
{%- do default_settings["values"].update(
{
"map_jinja": _map_settings["values"]
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
}
) %}
{#- Work around assignment inside for loop #}
{#- load configuration values used in `config.get` merging strategies #}
{%- set _config = {
"stack": default_settings.get("values", {}),
"merge_strategy": salt["config.get"](tplroot ~ ":strategy", None),
"merge_lists": salt["config.get"](tplroot ~ ":merge_lists", False),
} %}
{#- `parse_matchers` returns a `list` of `dict` with #}
{#- - type: `F` to load file, `C`, `G`, `I` for lookup #}
{#- - option: specific to the type #}
{#- - query: which key is requested #}
{#- - query_delimiter: the separator between query component #}
{#- - query_method: the salt method doing the query `config.get`, `pillar.get` and `grains.get` #}
{#- - value: the result of the `salt[<query_method>](<query>)` #}
{%- set map_matchers = parse_matchers(
matchers=map_sources,
config_get_strategy=_config["merge_strategy"],
log_prefix="map.jinja: "
)
| load_yaml %}
{%- for matcher in map_matchers %}
{%- if matcher.type in query_map.keys() %}
{#- Merge in `mapdata.<query>` instead of directcly in `mapdata` #}
{%- set is_sub_key = matcher.option | default(False) == "SUB" %}
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
{#- `slsutil.merge` defaults to `smart` instead of `None` for `config.get` #}
{%- set _strategy = _config["merge_strategy"] | default("smart", boolean=True) %}
{%- do salt["log.debug"](
"map.jinja: merge "
~ "sub key " * is_sub_key
~ "'"
~ matcher.query
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
~ "' retrieved with '"
~ matcher.query_method
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
~ "', merge: strategy='"
~ _strategy
~ "', lists='"
~ _config["merge_lists"]
~ "'"
) %}
{#- empty value is an empty list, it must be an empty dict for `.update` #}
{%- set value = matcher.value | default({}, boolean=True) %}
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
{%- if is_sub_key %}
{#- Merge values with `mapdata.<key>`, `<key>` and `<key>:lookup` are merged together #}
{%- set value = { matcher.query | regex_replace("(:lookup)?$", ""): value } %}
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
{%- endif %}
{%- do _config.update(
{
"stack": salt["slsutil.merge"](
_config["stack"],
value,
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
strategy=_strategy,
merge_lists=_config["merge_lists"],
)
}
) %}
{%- else %}
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
{#- Load YAML file matching the grain/pillar/... #}
{#- Fallback to use the source name as a direct filename #}
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
{#- Mangle `source_key` to use it as literal path #}
{%- if matcher.value | length == 0 %}
{%- set query_parts = matcher.query.split("/") %}
{%- set map_dirname = query_parts[0:-1] | join("/") %}
{%- set map_values = query_parts[-1] | regex_replace("(\.yaml)?$", ".yaml") %}
{%- else %}
{%- set map_dirname = matcher.query %}
{%- set map_values = matcher.value %}
{%- endif %}
{#- Some configuration return list #}
{%- if map_values is string %}
{%- set map_values = [map_values] %}
{%- endif %}
{#- `map_dirname` can be an empty string with literal path like `myconf.yaml` #}
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
{%- set yaml_dir = [
map_sources_dir,
map_dirname
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
]
| select
| join("/") %}
{%- for map_value in map_values %}
{%- set yamlfile = [
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
yaml_dir,
map_value ~ ".yaml"
]
feat(map): use targeting like syntax for configuration 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
2021-01-11 17:31:22 +01:00
| join("/") %}
{%- do salt["log.debug"]("map.jinja: load parameters from file " ~ yamlfile) %}
{%- load_yaml as loaded_values %}
{%- include yamlfile ignore missing %}
{%- endload %}
{%- if loaded_values %}
{#- Merge loaded values on the stack #}
{%- do salt["log.debug"]("map.jinja: merge parameters from " ~ yamlfile) %}
{%- do _config.update(
{
"stack": salt["slsutil.merge"](
_config["stack"],
loaded_values.get("values", {}),
strategy=loaded_values.get("strategy", "smart"),
merge_lists=loaded_values.get("merge_lists", False)
| to_bool,
)
}
) %}
{%- endif %}
{%- endfor %}
{%- endif %}
{%- endfor %}
{%- do salt["log.debug"]("map.jinja: save parameters in variable 'mapdata'") %}
{%- set mapdata = _config["stack"] %}