How to use roles from the command line?

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.

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.

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?

john.mee@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).

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

“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.

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

Interesting.

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

Hmmmm.

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?

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.

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

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.

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