On Sunday, October 20, 2013 at 10:43:30 AM UTC-6, Michael DeHaan wrote:
>
> "I want to be able to specify what tags I want to be run for a role in the 
> playbook instead of on the command line"
>
> Ok, so this is about selectively including *part* of a role.
>
> Yeah, we don't want do that.
>
> What should happen here is you should break the role into smaller parts 
> and leverage role dependencies.
>
>
This isn't a great universal solution. I understand why you might be 
hesitant about selectively including part of a role, but in reality, a 
cloud topology may have many interdependencies between them. For example:

I have a nagios role. It installs nagios, apache, a bunch of nagios 
plugins, and configures it based on members of other groups which come from 
dynamic inventory. One of my nagios tags is "update_config". When I 
provision new nodes from another playbook I want to depend on nagios role 
and *only* run the update_config tasks. I can run the others safely, but it 
takes *much* longer. Separating update_config to a "nagios_update_config" 
role seems silly to me. If I continue doing this, I'll end up with ~5 
sub-roles for every 1 role.

Thoughts?

 

>
>
>
> On Sun, Oct 20, 2013 at 11:30 AM, David Karban <[email protected] 
> <javascript:>> wrote:
>
>> What about to do a client role and server role and have. Client role will 
>> have only what client need and server role will have client role as a 
>> dependency and add server specific stuff?
>>
>> I know you wrote, that you do not separate roles, but I have feeling you 
>> are missing role dependencies?
>>
>>
>>
>> 2013/10/20 <[email protected] <javascript:>>
>>
>> I want to be able to specify what tags I want to be run for a role in the 
>>> playbook instead of on the command line. So to use what I'm doing now as an 
>>> example, I'm trying to deploy an application that has a server and a 
>>> client. They share a lot of the same tasks for installation. Servers will 
>>> get all of the server files including client files while the clients only 
>>> get the client related files. I didn't want to have to split things up into 
>>> roles for this because it seemed like unnecessary sprawl. What I ended up 
>>> doing in the interim which I got the idea from the previous post is just 
>>> use conditional logic and variables. 
>>>
>>> Here is what I put in my playbook:
>>> - {role: application, client_only: true}
>>>
>>> Then in my role for tasks that are only required for servers I added:
>>>
>>> when: client_only is not defined
>>>
>>> Instead of doing this I'd like to just use tags and be able to invoke 
>>> tags from within the playbook. I understand that you can do it on the 
>>> command line but some of the other users who use ansible or even myself may 
>>> forget to add the "client" tag or whatever when they run something. This 
>>> would help prevent that.
>>>
>>> -- 
>>> 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:>.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> -- 
>> David Karban
>> Specialista na správu linuxových serverů
>> www.karban.eu
>>
>> -- 
>> 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:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> -- 
> Michael DeHaan <[email protected] <javascript:>>
> CTO, AnsibleWorks, Inc.
> http://www.ansibleworks.com/
>
>

-- 
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/880df770-26f5-472e-a84d-d487e7f803e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to