Here's the idiom:
tasks:
- shell: foo
notify:
- ack
- bar
handlers:
- name: ack
when: some_condition
- name: bar
when: not some_condition
On Wed, Jun 25, 2014 at 8:10 PM, Michael DeHaan wrote:
> No, you cannot notify based on a fact.
>
>
>
>
>
No, you cannot notify based on a fact.
On Wed, Jun 25, 2014 at 4:22 AM, Nico K. wrote:
> That's exactly the workaround I'm using now, however you can't do
> something similar for 'notify'.
>
> e.g.
>
> notify:
> - reload {{ ansible_os_family }}
>
> doesn't work, putting a when clause on the
That's exactly the workaround I'm using now, however you can't do something
similar for 'notify'.
e.g.
notify:
- reload {{ ansible_os_family }}
doesn't work, putting a when clause on the entire block just for the sake
of using different notifiers means duplication of an entire block and aga
On Tue, Jun 24, 2014 at 12:36 PM, Christian Thiemann
wrote:
>
>
> On Tuesday, June 24, 2014 6:04:54 PM UTC+2, Michael DeHaan wrote:
>>
>> "It doesn't work for me (unless I create a file called
>> roles/foobar/tasks/{{ansible_os_family}}.yml... ;-) )."
>>
>> So in other words, it works :)
>>
>
> N
On Tuesday, June 24, 2014 6:04:54 PM UTC+2, Michael DeHaan wrote:
>
> "It doesn't work for me (unless I create a file called
> roles/foobar/tasks/{{ansible_os_family}}.yml... ;-) )."
>
> So in other words, it works :)
>
No, sorry, I meant literally "{{ansible_os_family}}.yml" -- it doesn't seem
"It doesn't work for me (unless I create a file called
roles/foobar/tasks/{{ansible_os_family}}.yml... ;-) )."
So in other words, it works :)
Also, public service announcement - Don't use ansible_pkg_mgr like that -
it won't join mulitple package installs using with_items into single
transactions
It doesn't work for me (unless I create a file called
roles/foobar/tasks/{{ansible_os_family}}.yml... ;-) ).
I abstracted away package manager things using the ansible_pkg_mgr fact:
- module: "{{ ansible_pkg_mgr }} name=foobar,baz,foo"
To account for OS-specific package names, you can do someth
It would be better to enhance the service module to understand launchd, but
that's a different topic.
On Tue, Jun 24, 2014 at 6:18 AM, Nico K. wrote:
> 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 abstra
On Mon, Jun 23, 2014 at 3:25 PM, Nico K. wrote:
> 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.
>
This is not true.
Task files in role
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
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 a
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: "{
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: D
13 matches
Mail list logo
