just on a whim, I thought I’d try this:
roles:
setup
{ role: worker, sudo_user: vagrant }
service
It didn’t work. No big deal, I can have three copies of the block. Switching from vars to vars_file will mean fewer repeated lines too. But if you feel like implementing it, a few of us would probably find it convenient.
Yep, sudo_user is to be set on the play, not the role.
I’m open to patches, but if done, it must also support “sudo: True/False” as well.
Sure, I’m interested too!
At the moment sudo_user is not fully detailed in Ansible Docs, and therefore I put here my experience feedbacks (aiming to maybe propose some “relevant” documentation addition?). About my context: I always connect with a non-root user, and switch between several accounts (root, service accounts, etc). I thus look for good sudo_user patterns.
So far, I experimented these two possible approaches (and did not find other ones):
sudo_user does not overwrite potential sudo_user at task levelhandlers, role vars files imported in previous plays are not implicitly available for subsequent plays.- explicit sudo_user for each task not executed by “single” default usersudo_user repetition for sequence of tasks executed by the same userTo summarize:
sudo_user at role level sounds like “the” good solution to disadvantages of both variants above. Should include also support it?Gilles
As for play vs task, I think it’s fine if people do either.
I’m curious why you think it’s not fully mentioned in the docs, can you give a link to where you think it needs to be talked about more? Or are you saying it’s not shown that you can set it on a task?
Sorry Michael for giving too few details about my documentation critics and wishes. With “not fully detailed”, I had following in mind:
sudo_user (at the moment) only supports variables defined at playbook level (as reported in GH 1665 and other related issues).For instance, I wonder if we could consider extending things like:
sudo_user can be applied to play and task)Thanks for all your awesome work Michael, and good luck for releasing 1.2 so soon!!! I’ll try my best to contribute to this great project (unfortunately with few time, and few skills).
Gilles
- Bryan are you already working on a patch?
No, I'm not. The workaround of putting several plays in a single playbook
works well enough for me. It's awkward, but not awkward enough that I've
started working on a patch.
Bryan
You could just set “sudo_user” on each task that needed a sudo user too.
I've been passing in a role parameter with the user, and then putting
sudo_user on each task.
It's clunky but works.
I'd be in favor of this change.
Overall, I don't think roles are very well defined. It seems like
they are intended to be more re-usable than playbooks (and
host-agnostic), but they aren't easy to parameterize.
Compared to implementing roles as just another task( "action: role
name=whatever" ), roles allow more flexible variable definition, but
not the other task modifiers like sudo/sudo_user.
If role invocation were more like tasks, the before/after stuff
wouldn't be needed, either. (Moving from a linear order to linear
within before/during/after phases is a code smell to me.)
Happy to chat more about it on Thursday. 
David
“Overall, I don’t think roles are very well defined. It seems like
they are intended to be more re-usable than playbooks (and
host-agnostic), but they aren’t easy to parameterize.”
I strongly disagree.
Roles are tasks.
but tasks with local handlers, local files, correct?
-sv
Yes, they’ve got a lot more on top, what I mean here is they can be parameterized exactly like tasks, in that you can send variables to them.
See: http://www.ansibleworks.com/docs/playbooks.html#roles
They clearly have a lot of resemblance to Puppet modules – they were very clearly inspired by that idea, but making them (IMHO) simpler and easier to use.
Reusability, encapsulation, simpler pathing, are all benefits.
And the example above shows they can be parameterized just like task includes.
Do they accept all the same parameters and modifiers as tasks? E.g.
when, ignore_errors, with_items, etc.?
My understanding is "no" -- which was the OP about "sudo_user" not
working on a role.
This is what I mean when I say "not very well defined".
The are *similar* to tasks, but they are *not* tasks. They have
different modifiers and can't be interspersed with other tasks. (E.g.
"task", "role", "task", "role")
As I said, I think this is a code smell -- because it would make much
more sense if one could reason about them and use them identically to
tasks, just with a little bit of extra indirection (expanding into a
large set of parameterized tasks with local files, templates,
handlers, etc.).
If 1.3 could find a way to let roles be used within a task list with
all the same features, I think that would be a great step towards a
more consistent design.
David
with_items and an include isn’t supported anywhere, we’ve undocumented it for good reason.
They are completely tasks.
What you are talking about is whether they take some include parameters that the task include line can take, which I’m all in favor of making it take sudo_user, and someone should send me a patch for it.
Lists and roles will never be supported, just as with task includes, you should loop inside the task.
Replying to the rest of this.
Rather than mixing roles and tasks, in your case, what you should do is use roles and convert your existing tasks into roles.
Roles can contain tasks of course, and also vars_files and handlers.
Then you can place them in any order you like for the task portions.
This keeps everything much simpler and self contained, without introducing more syntax.
Happy to just drop a note to “close” this outdated thread since sudo/sudo_user will be part of Ansible 1.3. Cool!!!
See