How to use roles from the command line?

[john...@caradvice.com.au]

I want to develop/test my new role on a virtual node thence apply just that one play, um role, against a host that really matters.

How do I do that without having to edit any files between getting it finished and applying it to production?

# this doesn't work...

% ansible-playbook -i testing roles/thisone?

% ansible-playbook -i production roles/thisone?

--tags thisone  

looked promising but it would mean going through everything applying tags, and then trying to remember what I called them all.

[James Cammarata]

If you're just testing that one role, why not make a simple playbook that calls just that?

- hosts: all

  roles:

  - thisone

That should be all you need, since you're pointing it at different inventory sources.

--
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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/eba3fed7-46af-4c80-9d41-573bd34d5711%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[john...@caradvice.com.au]

without having to edit any files between getting it finished...

Methodological issue, not practical: it feels dirty to edit a file between the test and the application.

Is creating and editing a new file the only way to get from the "tested" codebase to applying it to production hosts?

[Tomasz Kontusz]

john...@caradvice.com.au napisał:

>
>>
>> without having to edit any files between getting it finished...
>
>
>Methodological issue, not practical: it feels dirty to edit a file
>between
>the test and the application.
>Is creating and editing a new file the only way to get from the
>"tested"
>codebase to applying it to production hosts?

I'm using a combination of tags and --limit. I tag roles at the play level:

- hosts: db
roles:
- {name: common, tags: common}
- {name: postgresql, tags: postgresql}

And then use "ansible-playbook -i staging/inv -l db --tags postgresql" to only run that one role.

On the other hand, do you really want to run only that new role, and whole of it?
It might be enough to just use --limit, or you might want to use more tags inside role (I'm using "bbb" for trying only some tasks when debugging).

>
>On Tuesday, June 3, 2014 1:47:43 PM UTC+10, James Cammarata wrote:
>>
>> If you're just testing that one role, why not make a simple playbook
>that
>> calls just that?
>>
>> - hosts: all
>> roles:
>> - thisone
>>
>> That should be all you need, since you're pointing it at different
>> inventory sources.
>>
>>
>> On Mon, Jun 2, 2014 at 10:06 PM, <john...@caradvice.com.au

><javascript:>>

>> wrote:
>>
>>> I want to develop/test my new role on a virtual node thence apply
>just
>>> that one play, um role, against a host that really matters.
>>> How do I do that without having to edit any files between getting it
>
>>> finished and applying it to production?
>>>
>>> # this doesn't work...
>>>
>>> % ansible-playbook -i testing roles/thisone?
>>> % ansible-playbook -i production roles/thisone?
>>>
>>>
>>> --tags thisone
>>>
>>> looked promising but it would mean going through everything applying
>
>>> tags, and then trying to remember what I called them all.
>>>
>>> --
>>> 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 ansible-proje...@googlegroups.com <javascript:>.

>>> To post to this group, send email to ansible...@googlegroups.com

>>> <javascript:>.

>>> To view this discussion on the web visit
>>>
>https://groups.google.com/d/msgid/ansible-project/eba3fed7-46af-4c80-9d41-573bd34d5711%40googlegroups.com
>
>>>

><https://groups.google.com/d/msgid/ansible-project/eba3fed7-46af-4c80-9d41-573bd34d5711%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .

>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

--
Wysłane za pomocą K-9 Mail.

[Adam Morris]

On Monday, June 2, 2014 9:58:37 PM UTC-7, john...@caradvice.com.au wrote:

without having to edit any files between getting it finished...

Methodological issue, not practical: it feels dirty to edit a file between the test and the application.

Is creating and editing a new file the only way to get from the "tested" codebase to applying it to production hosts?

A role can have default variables overridden, depending on what it is it could be a simple task or a more complicated group of tasks...  

A play can include more than one role, and is used to tie the role(s) to one or more hosts.  So you probably do need to create a playbook like the one that James listed...  then in your case you use something similar to your original attempt...

ansible-playbook -i testing thisplay # Apply the role to all of the hosts in the testing inventory

ansible-playbook -i production thisplay # Apply the role to all of the hosts in the production inventory

ansible-playbook -i training thisplay -l justonehost # Apply the role to justonehost in the training inventory

No changes need to be made to any files between these different commands

I hope that this helps,

Adam

[Michael DeHaan]

"Methodological issue, not practical: it feels dirty to edit a file between the test and the application."

I wouldn't look at it this way.

To edit the role, perhaps, likely, yes.

But the idea that a playbook is simply mapping roles to hosts -- and keeping playbooks at top level very simple -- should be ok.

--
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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/d6619e20-df48-4da7-9bd7-991268b0263e%40googlegroups.com.

[Marc Abramowitz]

I agree with you. I find it a bit tedious to have to create a playbook just to apply a role.

You might be interested in this PR, which I just submitted:

https://github.com/ansible/ansible/pull/11416

[Greg DeKoenigsberg]

Interesting.

Not sure what the impediments are. It would certainly make Galaxy
testing easier, though.

Hmmmm.

> --
> 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 ansible-proje...@googlegroups.com.
> To post to this group, send email to ansible...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ansible-project/41672f8a-3861-4b64-8325-728c3bea91c5%40googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
Greg DeKoenigsberg
Ansible Community Guy

Find out why SD Times named Ansible
their #1 Company to Watch in 2015:
http://sdtimes.com/companies-watch-2015/

[Brian Coca]

fact gathering is one issue I see, off the bat. The template module is
hardcoded to error on adhoc, because of this.




--
Brian Coca

[Marc Abramowitz]

On Monday, June 29, 2015 at 5:51:15 AM UTC-7, Brian Coca wrote:

fact gathering is one issue I see, off the bat. The template module is
hardcoded to error on adhoc, because of this.

I'm not following. Can you elaborate on this? 

[Brian Coca]

in current ansible stable's template:

if not self.runner.is_playbook:
raise errors.AnsibleError("in current versions of ansible,
templates are only usable in playbooks")


I was looking of ways around this to allow for users to actually use
template ad-hoc, i was thinking of chainging ansible -m setup|ansible
-m template and consume the facts as 'extra vars', but I have not had
time to get into that.

--
Brian Coca

[Dave Hatton]

Maybe you have discountred something like this? I I have a simple stub playbook that I pass parameters to.


---
# Play:   run_role.yml
# Usage:  ansible-playbook -i ~/ansible/invs ~/ansible/run_role.yml -e "ROLE=<role>" -e "TARGETIP=<n.n.n.n|host@fqdn>"

- hosts:  '{{TARGETIP}}'
  user:    ansible
  sudo:    true

  roles:
  - { role: '{{ROLE}}' }

[Marc Abramowitz]

Thanks, Dave! Yeah, that's what we do now. I have a very similar playbook that we use to run a single role and that one playbook keeps us from having a zillion little playbooks. It works but it feels a little weird and and perhaps too clever.

[Marc Abramowitz]

OK, well I ended building a little thing. I haven't played with it much. Feedback welcome.

[Marc Abramowitz]

On Monday, July 6, 2015 at 11:52:24 AM UTC-7, Marc Abramowitz wrote:

OK, well I ended building a little thing. I haven't played with it much. Feedback welcome.

It would help I would guess if I gave the URL:

https://github.com/msabramo/ansible_role_apply