We can already do this by listing multiple plays in the playbook, and this has existed since basically day one. When you need to start a new user, start a new play. A playbook is a list of plays, it doesn’t contain just one play.
I feel I need to dead-horse this a bit, but my goal for Ansible, as listed on the project page, are to keep it extremely minimal. This means that there may not be ten syntactically equivalent ways to do the same thing. In many cases, there will be exactly one way, and this way, everybody writes things the same, and it’s obvious, and more importantly… there is very little code to maintain. I feel that the idea of X overriding Y is very much a programming language level concept, and Ansible is not a programming language. As such, it makes sense that, for the most part, things are defined in one and only one place.
In the proposed example, it’s particularly confusing. The play says user=ubuntu+sudo=True, which means log is as ubuntu and sudo to root. Then the task says user=bob, but didn’t say sudo=False, so it logs in as bob and sudo’s to root. Equivalent, and didn’t achieve anything. As a result, features like this end up spawning tons of user questions, where as if we have ONE way to do it, that isn’t error prone, it’s simple and obvious, and we can’t create this class of error and confusion.
This is basically what happened to Puppet and Chef. They started small, and they accepted too many feature requests, and they became complicated. So, I’m basically following something akin to the Zen of Python here – there should be one logical way to do things. In this case, it’s multiple plays in a playbook, swapping between plays for steps that need to be done as different users.
OT – To some extent we ALREADY have too many ways to do things (YAML vs INI inventory, proposed libssh2 vs paramiko) and this alone is extra to maintain. Ultimately what I feel is the RIGHT thing to do here, is write a script that reads the YAML inventory and converts it to the INI format (so people aren’t screwed on the upgrade path), and switch completely to libssh2 if it proves it’s worth. This keeps up our goals of having less to maintain, and less ways to do equivalent things. The very essence of ansible and how well it fulfills those goals should be judged by it’s total lines of code in the core (not modules, just core).
–Michael