Thanks for the thoughts Brian.
> You could have the first task attempt to 'connect as root and set
> the other user', ignore their failure and continue with rest of
> play with correct credentials
This is a new idea to me. Obviously some smell around ignoring failures.
> You could skip the 'as root' tasks depending on a passed var
Requires operator knowledge of state.
> Variation on the above, have the play update host_vars for that host
> with needs_root=False and have needs_root=True in group_vars/all.yml
> after updating the machine to not need root.
This is interesting. In effect, I'm keeping knowledge of state on the
local machine. Downsides might be - others operators don't have my
machine's state knowledge, I've built a non-obvious state mechanism,
and some machines in a group may fail, thus the state of the group is
not necessarily accurate.
> Another variation, add the host to 'doesnt_need_root' group in play
Interesting idea. Then the inventory sort of becomes a text-based
database, manipulated by plays. Yuck.
Which of these seems cleanest to you? The automatic ones all feel
like complicated mechanisms built on top of Ansible that sort of go
against the ideology of Ansible.
~gb
--
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/5e8305a8-befc-91b0-263f-9c090c2579ef%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
