I guess this has nothing to with assemble, as this has the same problem
copy:
content: "# {{ansible_managed}}\n\n"
dest: "{{kibana_confd_dir}}/00-kibana-header.yml"
So there is something I do not understand about the scope of
ansible_managed.
--
You received this message because you
On Saturday, June 6, 2015 at 9:08:36 AM UTC+5:30, Brian Coca wrote:
>
> did you install ansible via homebrew?
>
Hmm, I really don't remember. I could have been via pip. But I'm guessing
that I did whatever the install the instructions said because when I first
installed ansible (and started u
I am using assemble like so:
- name: Assemble the final kibana.yml
assemble:
src: "{{kibana_confd_dir}}"
dest: "{{kibana_config_dir}}/kibana.yml"
delimiter: "# {{ansible_managed}}"
owner: "{{kibana_user}}"
group: "{{kibana_group}}"
mode: 0644
Which yields:
TASK: [kiban
Updates didn't fix it, but I figured it out. I'm attempting to incorporate
some ansible calls into zenoss monitoring ultimately and had been making my
attempts as the application id, which is configured to use the
application's bundled python. Must have gotten lucky when testing Linux
guests,
no, play/roles/includes get compiled into a task list on the 'master',
once this is done each task is individually handled on the target
server, only the task code itself and arguments are copied to the
machine and then executed.
On Sat, Jun 6, 2015 at 1:06 PM, wrote:
> Thank you Brian for your
Thank you Brian for your explanation. I'm new to Ansible and don't
understand it perfectly. But it's better now. I use mainly Ansible in
the"pull" way, but it could be possible the other way round.
What I could do is to use the copy module to copy the Ansible role file
into a known temp file (/
Boto is required on the host it runs on.
There is no way to execute boto specific things on "test" when it is only
installed on local host.
What you can do is something like collect information on "test" then run
boto stuff on "localhost".
/martin
On Sat 6 Jun 2015 at 05:53 David Pires wrote:
I would like the same feature.
I don't know if there is another way to do what I am trying to do.
My case of use would be to be able to use the same roles/playbooks to
mantain the configuration along all my servers and for the AMI creation. In
the case of an ami creation I don't want the service
