Using a defined group_var over an undefined host_var (or how to hack variable precedence)

[Eric Brewer]

I have a scenario where I need to be able to specify to use the group_vars for a NTP timeserver, unless the host_vars are defined.  All of the variables are going to be coming out of an intermediary document that the customer is going to be filling out, like this:

vars/customer_vars.yml

timeserver1_default: 1.1.1.1
timeserver2_default: 1.1.1.2
timeserver1_server1: 1.1.1.3
timeserver2_server1: 1.1.1.4
timeserver2_server2: ~
timeserver2_server2: ~

The above referenced variable file will be called in the playbook itself using the vars_files module.  And I know that host_vars take precedence over group_vars, so i would like to be able to do this:

group_vars/all.yml

timeserver1: "{{ timeserver1_default }}"
timeserver2: "{{ timeserver2_default }}"

host_vars/server1.yml

timeserver1: "{{ timeserver1_server1 }}"
timeserver2: "{{ timeserver2_server2 }}"

host_vars/server2.yml

timeserver1: "{{ timeserver1_server2 }}"
timeserver2: "{{ timeserver2_server2 }}"

But I need to find a way around the fact, that if the host_var is defined in any way, even if its empty, that's the one that gets used.  Does anyone know a way to default to a group_var if a host_var is empty? I could rename the group_var ones and then write 2 different version of the conf file, pulling one if the host_var is empty for a particular server and another if its not, but I would really not have to have multiple versions of the same form.  It would seem like there is a better way of doing this that I just don't know, but maybe not.......

Thanks!

[Branko Majic]

On Tue, 18 Dec 2018 08:28:18 -0800 (PST)
Eric Brewer <ube...@gmail.com> wrote:

> I have a scenario where I need to be able to specify to use the
> group_vars for a NTP timeserver, unless the host_vars are defined.
> All of the variables are going to be coming out of an intermediary
> document that the customer is going to be filling out, like this:
>
> vars/customer_vars.yml
> timeserver1_default: 1.1.1.1
> timeserver2_default: 1.1.1.2
> timeserver1_server1: 1.1.1.3
> timeserver2_server1: 1.1.1.4
> timeserver2_server2: ~
> timeserver2_server2: ~

Perhaps you have already thought about it, but any reason why you
wouldn't make this into a list of NTP servers instead?

E.g.

timeservers:
- 1.1.1.1
- 1.1.1.2

This lets you easily override values per-group and per-host
basis, and also makes it pretty clear on what's going on.

> But I need to find a way around the fact, that if the host_var is
> defined in any way, even if its empty, that's the one that gets
> used. Does anyone know a way to default to a group_var if a host_var
> is empty? I could rename the group_var ones and then write 2
> different version of the conf file, pulling one if the host_var is
> empty for a particular server and another if its not, but I would
> really not have to have multiple versions of the same form. It would
> seem like there is a better way of doing this that I just don't know,
> but maybe not.......

This is going to be one of "those" answers, but the way you are
describing it looks to be a bit overcomplicated to me. E.g. even if it
can be done, sounds like it would be rather fiddly and unintuitive when
you decide to make configuration changes.

Best regards

--
Branko Majic
XMPP: bra...@majic.rs
Please use only Free formats when sending attachments to me.

Бранко Мајић
XMPP: bra...@majic.rs
Молим вас да додатке шаљете искључиво у слободним форматима.

[Eric Brewer]

Yeah, that would make it easier, but my constraint is at  the time of writing the code, I won't be able to tell which variable needs to be applied.  Most often, all of the servers are going to use the same IP's for their NTP servers, but I have to leave an option in for one or more servers to use a specific NTP server IP.  My variable file was a simplified version of the form that we need to hand out.  What will be handed out is a yml file with variable names and comments in place to explain the purpose of each variable, and instructions on what to fill out and when.  So I need to system to be flexible enough that it can use the same IP's for NTP for every server, except for where it is specified to be different based on what was and was not filled out on this form.  I would rather have built the customer form into a spreadsheet where I could have had a sheet dynamically filled out, and then referenced specific cells with a lookup, but I'm not allowed to use anything but this yml form in the requirements.  But thank you for the suggestion!

[Kai Stian Olstad]

On Tuesday, 18 December 2018 19:45:19 CET Eric Brewer wrote:
> Yeah, that would make it easier, but my constraint is at the time of
> writing the code, I won't be able to tell which variable needs to be
> applied. Most often, all of the servers are going to use the same IP's for
> their NTP servers, but I have to leave an option in for one or more servers
> to use a specific NTP server IP.

You can do that more easily but checking it a specific variable do exist if not use the default one
{{ hostvars[inventory_hostname]['timeserver1_' ~ inventory_hostname] | default(timeserver1_default) }}

> My variable file was a simplified version
> of the form that we need to hand out. What will be handed out is a yml
> file with variable names and comments in place to explain the purpose of
> each variable, and instructions on what to fill out and when.

With the above solution is should be easy to explain.

> So I need to
> system to be flexible enough that it can use the same IP's for NTP for
> every server, except for where it is specified to be different based on
> what was and was not filled out on this form.

It's a lot easier to deal with variables not set in Ansible, than the content of them.
So if you have the option to leave them out of the configuration instead of making them empty.

And in your case it's a lot cleaner and easier to use include_vars instead of populate host_vars.


--
Kai Stian Olstad