Here is a slightly odd technique that you could possibly use.
The first step would be to make your 'role/defaults' data structure. In my
example it looks like this:
car:
make: "{{ makevar }}"
model: "{{ modelvar }}"
year: "{{ yearvar }}"
condition:
paint: "{{ paintvar }}"
frame: "{{ framvar }}"
Notice that I am parameterizing all the values and the default is merely
functioning as the skeleton.
Now in 'group_vars/all' I wrote this in:
makevar: Ford
modelvar: Mustang
yearvar: 2009
paintvar: Great
framvar: Excellent
This establishes the default values for the initial data structure.
Now for the purposes of my example I made a simple role with the following
task:
- name: Show this value
debug: var=car.model
- name: show this other value
debug: var=car.make
- name: this deeper value
debug: var=car.condition.paint
when I run the playbook, it renders the values correctly. Now of course you
could flip the group_vars/all with somerole/defaults and it would work the
same, it would come down to matter of preference, your needs in terms of
variable precedence and how you plan to structure the rest of your Ansible
setup.
Let's assume the role is called 'coolrole' if you need to override specific
parts in various instantiations of the role you would do something like the
following:
---
- name: Spin up instances for testing
connection: local
hosts: localhost
roles:
- { role: coolrole, modelvar: GT }
Notice the modelvar variable is being overwritten for this particular
instantiation of the role.
I think this should help you, but let me know if something didn't makes
sense.
Cheers!
On Thursday, March 12, 2015 at 1:06:20 PM UTC-4, Duncan Hutty wrote:
>
> I'd like to have a pattern for roles where I can:
>
> 1) set default values in defaults/default.yml
> 2) override certain parts of a deep data structure in
> defaults/{{ansible_distribution}}.yml
> 3) allow individual instantiations of that role to override specific
> parts of it.
>
>
> I have a complex data structure for configuring the settings of a
> certain software.
>
> A more or less complete yaml description of the data structure might be
> something like:
> --
> foo_app:
> config_dir: /etc/foo
> run_dir: /var/cache/foo
> pid_file: /var/run/foo/foo.pid
> user: foo-user
> group: foo-group
> interface: *
> port: 8888
> unix_socket: /var/run/foo.socket
> settings:
> cluster_members:
> - hostA
> - hostB
> - hostC
> cache_size: 8192
> client_timeout: 8s
> cluster_timeout: 1s
> ...
>
> In other words, a deep structure which is a dict, where the values of
> some of the (top-level) keys could be various datatypes, including lists
> or dicts themselves.
>
> I'd like to have templates which use this data structure look like:
>
> {% for key, value in foo_app.settings.iteritems() | sort %}
> {{ key }} = {{ value }}
> {% endfor %}
>
> partly because it's convenient, and partly because namespacing under
> foo_app is good defensive programming to reduce the chance that other
> roles will step on my vars.
>
> So in summary, what do we think is the best way to allow (1), (2) & (3)
> without
>
> a) requiring that the data structure is flattened into individual vars:
>
> --
> foo_app_config_dir: /etc/foo
> foo_app_settings_clustermembers:
> - hostA
> - hostB
> - hostC
>
> OR
>
> b) Ensuring that *every* declaration of the data structure contains
> *every* element of the data structure, not just the ones we want to
> override.
>
> Of course, I realise that I might just be going about this all wrong (or
> at least not Anisbly) - if that's the case, please feel free to point me
> at docs (or Galaxy roles or github repos for learning by example) that
> show the Right Way to approach roles with elegance with regards to
> multi-distribution support and other cases that call for
> inheritance/override flexibility.
> --
> Duncan Hutty
> http://www.allgoodbits.org
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/8ac21bbf-378c-45a7-81fd-09fcab4d6260%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
