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.