On 06/12/14 01:38, Michael DeHaan wrote:
Tasks take a no_log: True attribute to prevent their output from
hitting syslog, easiest is to also make this automatically dock the
verbosity in the callback.
Ok, this would surely be a fine solution to the problem of being able to
protect from over
Hi,
Thanks for pointing that out. I understood the concept now (specifying a tag to
a role means flagging all role's tasks with the tag).
The reason why I wanted to do it differently is because of the following
scenario:
Assume you have tasks in two different roles. First, you want to execute
For all my environments there are entire files that lend themselves best to
not be templated. Just one per environment will do.
I use roles, and my directory structure is as follows
├── env_iodtest [directory]
│ ├── group_vars [directory]
│ │ └── all [file]
for targets systems the 'replace' module can do this nicely, I would use
that even in 'localhost'
--
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
Hi all,
I cannot use facts for include variables. I think it's because the yaml
syntax checker fails (as they don't exits at that time):
My test play:
---
- hosts: localhost
gather_facts: true
tasks:
- include:
{{ansible_distribution}}{{ansible_distribution_major_version}}.yml
Hacky way that works.
- name: install vast.list.of.settings
copy: src=../../../{{ mule_environment
}}/files/vast.list.of.settings dest={{ mule_home }}/conf
Good or bad?
--
You received this message because you are subscribed to the Google Groups
Ansible Project group.
To unsubscribe from
Using lt's of conditionals get's pretty messy - IMHO it would be nicer if
it could be handled in seperate files.
I would love if syntax checks were a bit more relaxed here: If variables
in an include statement cannot be replaced just print a warning instead of
raising an error.
Am
Hi!
I think that this is not possible at this moment (I don't know if I'm wrong)
I want to load a common variables directory (*vars* for example like in
role levels) at playbook or inventory levels so I don't have to set the
*include_vars* or *vars_files* in each role or task.
I want to do
On 12 June 2014 15:42, Oliver Heinz oliver.heinz@googlemail.com wrote:
Using lt's of conditionals get's pretty messy - IMHO it would be nicer if
it could be handled in seperate files.
You can assign conditionals next to task includes or roles though.
--
You received this message
On 12 June 2014 15:35, jepper jespm...@gmail.com wrote:
- name: install vast.list.of.settings
copy: src=../../../{{ mule_environment
}}/files/vast.list.of.settings dest={{ mule_home }}/conf
Good or bad?
There's no problem using this. You might want to look if one of the
special vars
Thanks for pointing this out.
So
tasks:
- include:
{{ansible_distribution}}{{ansible_distribution_major_version}}.yml
would expand to
tasks:
- include: Debian6.yml
when: ansible_distribution == Debian AND
ansible_distribution_major_version == 6
- include: Debian7.yml
when:
Thanks for the reply Michael.
I came across the group_by module when Googling around but I didn't
understand how to use it until I started typing this reply. Below is an
edited version of my previously posted playbook snippet. The only question
I have is how should I skip the task Stopping
Hi there,
I saw an example sometime ago, either a thread,blog or IRC about executing
a single task in a playbook only once every 24 hours.
Can't find that example anywhere,
has anyone here has an example of how to achieve this ?
I have a task that syncs a mirror with a bunch of upstream repos,
The job consists mainly of moving configuration files betwen exact
topologies, at different locations, only that at the destination there will
be new server IP addresses, but all else pretty much the same. That should
not be too hard manually, but there are quite a few files per application
You can use group_by to avoid repeated conditionals.
Select the hosts where something is true and apply roles/tasks to the
dynamically created group.
On Thu, Jun 12, 2014 at 10:25 AM, Oliver Heinz
oliver.heinz@googlemail.com wrote:
Thanks for pointing this out.
So
tasks:
-
15 matches
Mail list logo
