I don't view roles as "just abstractions around tasks."  In fact just the 
opposite: tasks are the commands needed to implement a role. This is 
because I use roles as my primary CI. The baseline on a given host is made 
up of applications (a CI) and roles (a CI) and some hardware stuff. All the 
CIs are version per good CM practice.

If you are aren't using roles as your main CI then what are you using as 
the CI's in your baseline? The entire playbook? An individual task? 

How Ansible maps to and supports a formal CM process is an important 
question, at least to me. As my CM tool of choice I hope to see Ansible 
evolve in a way that facilitates CM best practices.  

Thanks,
Aaron


On Thursday, April 24, 2014 8:48:45 AM UTC-4, Michael DeHaan wrote:
>
> Peter, it sounds like you have a seperate issue with lookup paths, this 
> should be a seperate thread.
>
> All -- roles are just abstractions around tasks.  Tag your roles if you 
> like.
>
> roles:
>   - { role: foo, tags: foo }
>
> And you can --tags foo
>
> To just run those roles.
>
>
>
>
> On Thu, Apr 24, 2014 at 4:35 AM, Peter Gehres 
> <[email protected]<javascript:>
> > wrote:
>
>> In order to run roles separately I use this work around too. Since roles 
>>> are my primary configuration item (CI) I wanted to avoid this extra step. I 
>>> don't understand why tags have a command line option but roles don't. 
>>>
>>
>> A role is not a grouping mechanism. If there were a CLI option, how would 
>> you determine to which hosts the role is applied? You could have ansible 
>> determine all of the plays where the role is used, but that sounds like a 
>> hairy dict-inversion challenge that I imagine would over complicate the 
>> code.
>>
>> I would, instead, think about adding an "implicit_grouping: True" option 
>> to ansible.cfg whereby a role named "webserver" is mapped to a group called 
>> "webserver" with an implicit play of:
>>
>> hosts: webserver
>> roles:
>>   - webserver
>>
>> There are, however, implications here such as "how do I set other options 
>> on that play?" You start yak shaving fairly quickly and end up with feature 
>> creep to make it marginally useful for the majority of cases. This involves 
>> more configuration options and another syntax for defining the plays and we 
>> are right back where we started.
>>
>> N.B. - We use the play-per-role model and the "dirty" root of our 
>> playbooks directory bugs me to no end.  I would very much like to see the 
>> ability to stash them in a "plays" subdirectory and be able to include them 
>> in our site.yml without having relative-pathing lookup issues (i.e. they 
>> should execute in the context in which they are included, not the context 
>> in which the file sits. This also causes issues when you include, say, a 
>> play to spin up a particular role in ec2 and want to put that play inside 
>> the role, but execute it with the ability to act as if it were run in the 
>> playbooks root).
>>
>> Peter
>>
>>  -- 
>> 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/CABpn%2BqQX08JOgxfw1T11AK-BB2NiyDpLMxEX-LExTCnzxcnVfA%40mail.gmail.com<https://groups.google.com/d/msgid/ansible-project/CABpn%2BqQX08JOgxfw1T11AK-BB2NiyDpLMxEX-LExTCnzxcnVfA%40mail.gmail.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/d5ca2383-16e7-47c2-af69-fcdf24cc3829%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to