"AFAIU, this is exactly the use case for allow_duplicates=yes, isn’t it? "
This only deals with role deps. I feel I am repeating myself :)
"If we forget about dependencies for a bit, and consider the case where a
role is listed in two plays, which are both included in a top-level role.
Should th
On Fri, Jul 18, 2014 at 2:40 PM, Michael DeHaan wrote:
There are cases (again, parameterized roles) - different roles can have the
> same dependency with different parameters, where that doesn't make sense.)
>
AFAIU, this is exactly the use case for allow_duplicates=yes, isn’t it? It
would allow
There are cases (again, parameterized roles) - different roles can have the
same dependency with different parameters, where that doesn't make sense.)
People get too hung up on role dependencies. In most of the content we
write for customers, we actually don't use role deps at all. They are not
On Fri, Jul 18, 2014 at 4:34 AM, Michael DeHaan wrote:
Role dependencies can have parameters.
>
Isn’t that what allow_duplicates=yes is for?
Wouldn’t it be more consistent for allow_duplicates not to discriminate
between executing the role explicitly or as a dependency?
--
You received thi
On Thu, Jul 17, 2014 at 12:23 PM, Joseph Tate
wrote:
> On Thursday, July 17, 2014 5:30:44 AM UTC-7, Michael DeHaan wrote:
>>
>> Right! Good plan.
>>
>> You could do a "set_fact: role_has_executed=1" at the end of the role
>>
>> and then on the role:
>>
>> - role: { name: foo, when: "role_has_ex
On Thu, Jul 17, 2014 at 12:21 PM, Joseph Tate
wrote:
> Even if a role ends up being a no-op, it takes time. This makes playbook
> execution slower, which is annoying.
>
What good does it do to tell the list you are annoyed? Provide an
alternative, perhaps.
--
You received this message because
Even if a role ends up being a no-op, it takes time. This makes playbook
execution slower, which is annoying.
On Wednesday, July 16, 2014 5:22:34 PM UTC-7, Michael DeHaan wrote:
>
> Generally people should write roles so that they are idempotent (grr, that
> word again) and running them more tha
On Thursday, July 17, 2014 5:30:44 AM UTC-7, Michael DeHaan wrote:
>
> Right! Good plan.
>
> You could do a "set_fact: role_has_executed=1" at the end of the role
>
> and then on the role:
>
> - role: { name: foo, when: "role_has_executed is defined" }
>
Why would this not be default behavior?
Right! Good plan.
You could do a "set_fact: role_has_executed=1" at the end of the role
and then on the role:
- role: { name: foo, when: "role_has_executed is defined" }
On Thu, Jul 17, 2014 at 3:31 AM, Tony Marin wrote:
> You can try to set a condition on the whole role (you can use
You can try to set a condition on the whole role (you can use an empty
main.yml with an inmport: ... when: common_executed is defined) based
upon a fact/variable that you can define at the end of the common role,
thus if it has been executed once, it will be skipped afterwards.
On 17/07/14 00:
Generally people should write roles so that they are idempotent (grr, that
word again) and running them more than one time is a no-op.
If the operation is very destructive and you don't want to run it again,
maybe consider a touch file to indicate the configuration has been done
once.
I do unders
On Thu, Jul 17, 2014 at 2:53 AM, Michael DeHaan wrote:
Take a look at the "allow_duplicates" parameter.
>
> http://docs.ansible.com/playbooks_roles.html#id8
>
This does not solve my problem.
I’m happy with the default (allow_duplicates=no). My issue is that it only
prevents the same role from ex
Take a look at the "allow_duplicates" parameter.
http://docs.ansible.com/playbooks_roles.html#id8
On Wed, Jul 16, 2014 at 6:01 PM, Ahmad Khayyat wrote:
> I have a common role, which i always want executed, but only once. It is
> also a dependency of a few other roles that may be executed on
I have a common role, which i always want executed, but only once. It is
also a dependency of a few other roles that may be executed on their own
(via dedicated playbooks).
The problem is: in a top-level playbook, e.g. site.yml, if the common role
is listed anywhere (in site.yml or an included pla
14 matches
Mail list logo
