Re: [ansible-project] Re: Ansible Tasks reusability

2014-01-15 Thread Michael DeHaan
This should be unnecessary. groups of a lower tier will override the variables in the parent group. You can also engage blending hashes together versus overriding them if you want, via a setting in ansible.cfg. I should also point out this thread has now drifted off topic relative to it's

Re: [ansible-project] Re: Ansible Tasks reusability

2014-01-14 Thread Adam Morris
On Tuesday, January 14, 2014 5:45:09 AM UTC-8, Michael DeHaan wrote: syslog: {% if ansible_distribution_version|truncate(1,true,'') = '6' %}rsyslog{% else %}syslog{% endif %} That's super gross IMHO... I would not want to see that in *anyone's* playbooks as that goes against much of the

Re: [ansible-project] Re: Ansible Tasks reusability

2014-01-14 Thread Michael DeHaan
Oh I'm not offended, don't worry about that. I'm just suggesting (especially for new comers on the list), that it's better to try to simplify first than resort to Jinja in most cases -- I like to use it to insert variables and occasionally loop in templates, but limit it to just that whenever

Re: [ansible-project] Re: Ansible Tasks reusability

2014-01-13 Thread karakraken .
Yup. I've also been using 'default'. However, As showed in 'user' module example, problem is when there's no default value. ie in the case when certain users need to have supplementary group and some others do not have supplementary group. (there is no such thing as 'groups=item.group |

[ansible-project] Re: Ansible Tasks reusability

2014-01-13 Thread Adam Morris
On Tuesday, January 7, 2014 1:38:06 AM UTC-8, hafizh wrote: I notice that the tasks are very 'strict'. Once we provide an optional param, the rest of the lists must provide it too. Say. I want to create two users: vars: - users: - { name: test1, uid: 1234 }

[ansible-project] Re: Ansible Tasks reusability

2014-01-13 Thread bryan hunt
I had no idea that was possible, I've been using all sorts of kludges to achieve the same. On Monday, January 13, 2014 6:17:55 PM UTC, Adam Morris wrote: On Tuesday, January 7, 2014 1:38:06 AM UTC-8, hafizh wrote: I notice that the tasks are very 'strict'. Once we provide an optional

[ansible-project] Re: Ansible Tasks reusability

2014-01-12 Thread hafizh
Meh, Im bad at giving example. It's not 'file' module but 'copy' module. What i wanted to say is like this 1 just want to specify 'backup=yes' for 1 file only and use the default for the rest(dont want to specify 'backup=no') On Monday, January 13, 2014 12:56:55 PM UTC+8, hafizh wrote: Thanks

Re: [ansible-project] Re: Ansible Tasks reusability

2014-01-12 Thread Adam Morris
Actually that is pretty simple. You can set a default value for a variable either for a role or using a standard jinja2 filter... Copy: backup={{backupfile|default (no)}} At least I think that that should work. Adam. -- You received this message because you are subscribed to the Google

Re: [ansible-project] Re: Ansible Tasks reusability

2014-01-12 Thread Michael DeHaan
You should probably consider the |default feature in Jinja2 for fields you don't want to define a value for, and as Adam said, specify the UUID. This should take care of the above concerns. {{ item.shell | default('/bin/sh') }} etc On Sun, Jan 12, 2014 at 11:56 PM, hafizh

Re: [ansible-project] Re: Ansible Tasks reusability

2014-01-07 Thread Michael DeHaan
To generically answer the question, you could use a when conditional. The inference that Ansible isn't smart enough is incorrect, the content isn't smart enough :) ... yet. On Tue, Jan 7, 2014 at 3:33 PM, Adam Morris zwack...@gmail.com wrote: Actually, if it was up to me I would say that