To see how far I could come I went with the second approach that I
mentioned in my original post.
With some tinkering I managed to abstract away most of the differences,
it's way too chatty though but it works.
However, I am stuck with the Handlers. As 'service' isn't supported on OSX
I had the idea of defining my own Handler like:
- name: restart someservice
shell: launchctl {{ item }} {{ service_plist}}
with_items:
- stop
- start
when: ansible_os_family == "Darwin"
This works, except the 'when' clause isn't processed, after all as per the
manual, handlers are matched by name. I could then go down the lane of
naming the service accordingly:
- name: restart {{ ansible_os_family }}
however this doesn't work either as you can't seem to dynamically set the
name of a handler, so the only approach that I can think of that does work
is giving the handlers another name:
for example "restart nginx darwin / restart nginx ubuntu".
However that means that in my generic code where I change a file I will
have to make a choice which handler to notify based on the OS I'm running
on; same problem as before, you can't do:
notify:
- restart nginx {{ ansible_os_family }}
Things would be a lot easier if 'Service' would be implemented for OS-X and
package would be abstracted (like for example Salt does).
Op maandag 23 juni 2014 21:25:04 UTC+2 schreef Nico K.:
>
> Sure, but that's exactly the thing I would like to deal with within a
> role, within a role however you can't perform the 'include' you stated in
> your post as "ansible_os_family" doesn't seem to evaluate.
>
> Op maandag 23 juni 2014 20:33:42 UTC+2 schreef Michael DeHaan:
>>
>> Most all ansible modules already abstract out OS details.
>>
>> Package managers we want you to know - not only do package names change,
>> but the way you interact with those packages change - think of how
>> different Apache is between Ubuntu and CentOS for instance.
>>
>> You can do things like
>> - include: "{{ ansible_os_family }}.yml"
>>
>> And you can also do things like use "include_vars" with similar tricks
>> where you want to maintain differences.
>>
>> In most cases you'll only differ by variables except having a few tasks
>> with "when" statements on them keying off the OS - which will also minimize
>> task duplication.
>>
>>
>>
>>
>> On Mon, Jun 23, 2014 at 1:05 PM, Nico K. <nkrab...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> So I've been scavenging through a lot of posts to figure out how to deal
>>> with heterogeneous environments.
>>> The two approaches that I see most are either using "group_by" or using
>>> "when".
>>>
>>> For example:
>>>
>>> site.yml:
>>> - name: whatever
>>> tasks:
>>> - group_by: key={{ansible_os_family}
>>>
>>> - hosts: Debian
>>> roles:
>>> - role: rolename-debian
>>>
>>> - hosts: Darwin
>>> roles:
>>> - role: rolename-darwin
>>>
>>> My problem with this approach is that you are saying that a role is "OS"
>>> specific, even though it's not. Perhaps this has to do with my definition
>>> of role, but as I see it a 'role' is a task that any given node can perform.
>>> I should be able to assign the 'role' 'nginx' to a variety of hosts, how
>>> those hosts then implement that role should be defined within the 'role'
>>> definition.
>>>
>>> Now supposedly you can do this using the 'when' conditional statement,
>>> you would then end up with something like:
>>>
>>> roles/myRole/tasks
>>>
>>> - include: apt.yml
>>> when: ansible_os_family == "Debian"
>>>
>>> - include: brew.yml
>>> when ansible_os_family == "Darwin"
>>>
>>> However this is rather chatty, especially when these files include files
>>> of there own. And with chatty I mean every task, even when the 'when'
>>> clause is not matched is being shown, now you can set 'show_skipped_hosts"
>>> in the ansible configuration, however this still shows the headers of tasks
>>> that are (not) being processed.
>>>
>>> Should I be dealing with this in a different fashion?
>>> What I'm trying to accomplish is having a playbook that installs a
>>> package on a bunch of machines (running differents OS's), then configure
>>> that package based on the OS and configure the service accordingly.
>>>
>>> IMHO the latter approach is the way to go, however the 'chattyness' is
>>> killing my operators.
>>>
>>> Thanks a lot for sharing your insights.
>>>
>>> Best regards.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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-proje...@googlegroups.com.
>>> To post to this group, send email to ansible...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/ansible-project/61f300f9-bb1e-4ef3-89a3-c81637202fb5%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/ansible-project/61f300f9-bb1e-4ef3-89a3-c81637202fb5%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
--
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/aa367068-c9d2-4393-b23f-5c3d6ab1c4e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
