I just finished another take at describing a modest infrastructure in
playbooks. Trying to keep simplicity at the forefront, I found myself
wishing for a couple modest enhancements:
1. Process vars_files BEFORE vars. Use case is I set a lot of defaults
in common vars file, then want to interplate those values into more
specific variables, for example:
in vars file:
app_base_path: /usr/local/src/someapp
in setup:
subapp_base_path: ${app_base_path}/subapps/myapp
2. Conditional imports for tasks files. Use case is where I want to
apply a bundle of tasks based on distro or some other choice that
lends itself more to interpolation than hosts/groups filters, for
example:
- include: - [ "tasks/${facter_operatingsystem}_webserver.yml", "vars/
defaultos_webserver.yml" ]
I just finished another take at describing a modest infrastructure in
playbooks. Trying to keep simplicity at the forefront, I found myself
wishing for a couple modest enhancements:
- Process vars_files BEFORE vars. Use case is I set a lot of defaults
in common vars file, then want to interplate those values into more
specific variables, for example:
People like to use vars to define path prefixes, so this isn’t going to happen.
- Conditional imports for tasks files. Use case is where I want to
apply a bundle of tasks based on distro or some other choice that
lends itself more to interpolation than hosts/groups filters, for
example:
- include: - [ “tasks/${facter_operatingsystem}_webserver.yml”, “vars/
defaultos_webserver.yml” ]
This seems like it drives playbooks towards gross levels of complexity where you don’t know
what they will do.
Auditability (vs alternatives) was a major design goal, so I’m quite opposed to this kind of automagic.
This is where you should define groups of hosts and target the right plays at the right groups.
–Michael
> 1. Process vars_files BEFORE vars.
People like to use vars to define path prefixes, so this isn't going to happen.
That's a good hint. I can accomplish my use case that way.
> - include: - [ "tasks/${facter_operatingsystem}_webserver.yml", "vars/
> defaultos_webserver.yml" ]
This seems like it drives playbooks towards gross levels of complexity where you don't know
what they will do.
Auditability (vs alternatives) was a major design goal, so I'm quite opposed to this kind of automagic.
I appreciate you holding the ground against complexity--even when I'm
the one who is asking for it :).
Still, this complexity already exists for vars files. Seems like here
I'm just asking for some parity in tasks files. You're right that
groups could be used to accomplish this, but then I ask, can't groups
also accomplish what conditional vars_file imports do? Why the
difference?
We are not going to break backwards compat for this, sorry.
-- Michael