Thanks Michael.

In my example I have a backup role. It would like to know the path where 
the apache-role stores websites by default so that it can back them up. 
Lets say the apache role stores this variable as `apache_sites_dir` in its 
default/main.yml  (and of course it can be specified as well in inentory 
vars).

So I currently have the backup role depending on the apache role to glean 
this variable (I thought conventional). I didn't like this approach because 
it runs apache tasks -- so I added the skip_task garbage.

Is explicitly loading apache's agreeable in this situation? e.g.

:: backup/tasks/main.yml ::

- name: detect apache sites location
  include_vars: "'path/apache/defaults/main.yml"
  when: apache_sites_dir is not defined

```

or can you enlighten me upon a different approach.

Many Thanks,

~ Brice




On Tuesday, May 27, 2014 2:54:11 PM UTC-5, Michael DeHaan wrote:
>
>
> What you say is a "well understood ansible convention" I am having trouble 
> processing.
>
> I read most of your posts and think you are in general not getting the Zen 
> of Ansible too much.
>
> Keep things simple.
>
> Don't think about trying to read what some default value is.   Just use 
> the value that makes it through, knowing that the right value made it 
> through.
>
> The "skip_tasks" stuff, and other hacks should be shunned.
>
> Once you get the bare minimum to automate application X, stop.
>
> It's not supposed to be a super-elegant software construct, or even a 
> programming language.  It's a language for getting things done.
>
>
>
>
>
>
>
>
> On Tue, May 27, 2014 at 9:45 AM, Brice Burgess <[email protected]<javascript:>
> > wrote:
>
>> I often need to access the default variables of another role. Currently 
>> I'm doing this via role dependencies, and passing a special variable to 
>> skip running a roles tasks. E.g.
>>
>> ```
>>
>> :: my_role/meta/main.yml ::
>> dependencies:
>>   - { role: other_role, skip_tasks: True }
>>
>>
>> :: other_role/tasks/tasks.yml ::
>> - { include: prepare.yml, tags: ['prepare'], when: skip_tasks is not 
>> defined or not skip_tasks }
>>
>> ```
>>
>> This is nice because it accomplishes loading variables from other_role 
>> (default/main.yml, vars/main.yml) and is a well understood ansible 
>> convention... although it adds additional variable complexity (skip_tasks) 
>> and verbosity to the playbook output (all the skipped tasks are reported). 
>> As an alternative I am thinking about explicitly included the desired vars 
>> (if they are not already available). E.g.
>>
>> ```
>>
>> :: my_role/tasks/main.yml ::
>>
>> - name: gather variables
>>   include_vars: "'/path/to/other_role/defaults/main.yml"
>>   when: needed_var_from_other_role is not defined
>>
>> ```
>>
>> Is this a recommended approach? 
>>
>> Alternatively I could probably stick all shared variables in a taskless 
>> common role that's depended upon -- although prefer the naturality of 
>> keeping the vars in their related role.
>>
>> Thanks for your insight!
>>
>> ~ Brice
>>
>>  
>>
>> -- 
>> 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] <javascript:>.
>> To post to this group, send email to [email protected]<javascript:>
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/ansible-project/adb5acd6-9221-42c5-b0cd-313edafa3e38%40googlegroups.com<https://groups.google.com/d/msgid/ansible-project/adb5acd6-9221-42c5-b0cd-313edafa3e38%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/7a7786bc-7c71-45f1-b3ac-3be319f18aed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to