Last active
April 16, 2018 09:51
-
-
Save evrardjp/36427ce995f04f2d914e229e30b05650 to your computer and use it in GitHub Desktop.
Automatic checking of required vars -- New pattern to replace https://github.com/openstack/openstack-ansible-os_keystone/blob/16dafa4718a1b1f97e4d46a2359f7b2c4cf3a015/tasks/main.yml#L20
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- name: Load required variables | |
include_vars: | |
file: defaults/required.yml | |
name: "{{ testing | bool | ternary(omit,'required') }}" | |
- fail: | |
msg: "{{ item.key }} is not defined" | |
when: | |
- "vars[item.key] is not defined" | |
- not testing | |
with_dict: "{{ required | default({}) }}" |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Let me clarify that bit then.
The keystone role currently requires to know repo_server_port when deploying to production. This can be generalized to other examples: glance needs to know variable X (let's say "keystone_endpoint_url") representing the service catalog url of keystone for example.
Because of the first simplification we now know what should be defined as input of the role to make it work.
These inputs are, by default, wired into openstack-ansible group vars for example. They are reduced in size so that ansible runs fast.
These vars can be overriden by a deployer on a case by case basis using:
user_*.yml
We cannot say in advance where the deployer will override things, and if he overrides things.
The role should not care if the defaults were overriden or not.
If an override happens on
user_*.yml
, that's easy: the override would apply to all the nodes. But that's not the case with group_vars/host_vars. Let's say someone overrides keystone endpoint with a keystone group var. The glance group won't get that variable change but still he should be aware of it.Two ways to fix that:
The whole post above was for automatic wiring of variables following a play.
Let's continue the glance integration with keystone example, with a keystone group override of keystone endpoint url.
A role var in keystone could expose what would be its role' outputs. Let's say that variable listing the "integration points" (or outputs) would be named "source_of_truth_facts". That variable would be a list, and have an item "keystone_endpoint_url".
Benefits:
Example, let's say we have a source of truth etcd, or simply a flat file on the deploy node.
Inside the keystone playbook + role run, we know what the "keystone_endpoint_url" value is. We check the role's "source_of_truth_facts" variable, and we loop over its items. Each item is a variable itself that can be templated and uploaded to the source of truth. (For example, templating a static file on a node deploy node or other if the source of truth is a flat file).
Then other roles which would require the keystone_endpoint_url as input could be automatically wired by checking the templated result in the source of truth. So for example, reading a fact of the deploy node before running the role.
That brings a lot of flexibility, as the source of truth can be switched to something else.
Hope it helps