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. <[email protected]> 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 [email protected].
>>> To post to this group, send email to [email protected].
>>> 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 [email protected].
To post to this group, send email to [email protected].
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.
