Hey Folks,
Running into some odd behavior (currently on the devel branch) with
vars_prompt. What I am seeing are 2 things.
1) I get no console echo when inputting the variables that I prompt for.
I can't remember if we decided to mask the input of these variable
entirely or if there was a way to only mask certain variables we prompt
for. For these variables in particular I want to use, it would be good to
echo them. The only things we would want to prompt and not echo for would
be passwords/passphrases, imo.
vars_prompt is ONLY intended for passwords
Other variables should be version controlled with the PB. We have also
talked about reinstating --extra-args, which is going to happen, so a
release version you can just pass in on the command line.
Typing things is kinda against the point of automation, right? 
Ok, confirms the lack of echo, makes perfect sense. However if you are
going to do that, you might need to prompt twice and do a comparison if
it's going to set the password for something. If it's going to use the
password to carry out an auth action, probably not so much.
In the case of doing a version release, I don't think we can't assume that
people using the PBs have write access to them, as some orgs may have
separation of privileges and responsibilities. They may only have read and
hence couldn't modify or submit for version control. This is the problem
with my current config server at the moment. It controls releases so I
can't give my engineers the ability to do any deploys as they get much more
access to things (and the potential to break a lot) if they have write
access. --extra-args would be totally acceptable I also admit, I am
testing the include of a release file that contains version vars, so I did
think of that 
While I agree that typing things is kinda against the point of automation,
I'll say what I told my last VP (as he wanted to automate EVERYTHING and
would have phased out his Systems Engineers if he could, leaving only a
not-even Junior NOC to run things). Automation for me is one of many
tools, not an end solution or the only solution. You can't automate
everything but you strive to automate as much as you can. Some processes
do require a human at the wheel when dealing in certain markets and
institutions. Otherwise everyone runs around pointing fingers at each
other and blaming "the system" when something breaks or doesn't behave
properly. But it raises an interesting question.. If you extend ansible
into doing lots of automated tasks on a scheduled basis, you are somewhat
defeating your security as you are at some point enabling password-less
sudo on your clients, and potentially passphrase-less SSH keys (or setting
up an agent once on the overlord that needs to be kept an eye on). I was
trying to think how one could avoid some of these pitfalls if you really
wanted to be hands-off. Maybe I'm missing something somewhere, would love
for someone to shed some light on this for me if anyone can. My logic
surely isn't fool-proof ;).
2) I appear to get prompted twice for the variable input. In the
.ansible/setup file that gets created on the client machine, the values
entered via the second prompt are the ones present. Again, the only time
we would want to prompt twice (and do a comparison against the 2 inputs)
would be passwords/passphrases, and if there was a failure, re-prompt.
The variable name and the prompt should be printed on one line, like this:
dogs_out: Who Let The Dogs Out?
Patches welcome!
Not sure if I follow what you are saying here.. I've got them defined in
the playbook with that proper syntax. Did you mean something else? In the
example I gave below (this is output from the playbook run), when you are
prompted for the vars when running a playbook, you get prompted twice for
them, and if you enter different input each time, it doesn't complain and
takes the 2nd input.
Here's what I see..
[xx]$ ansible/bin/ansible-playbook site/deploy-servers.yml -K
sudo password:
Release to deploy?
input for release_version:
Who's your Daddy?
input for Daddy:
Release to deploy?
input for release_version:
Who's your Daddy?
input for Daddy:
A couple other things I have noticed during testing:
1) On the client machines, the setup file under .ansible is owned by root
(artifact of running through sudo?). I was able to delete it just happily
tho as myself after logging into the client directly.
Presumably. If running as sudo we should really use the root setup file
location. Someone want to fix this?
Not sure which way to go on that one. I think there are good cases for
root or the user, but the key thing is to make sure it isn't publicly
accessible by prying eyes if it contains any sensitive variables in case
you forget to come up from behind with another playbook to erase the
sensitive variables in the setup file.
2) If the playbook is interrupted for whatever reason, we get stale
files under .ansible/tmp. I can clean these out but they may never get
noticed otherwise if you didn't know to look for them.
I am thinking a cleanup module is probably warranted, that could be used
at the end of playbooks and such, or on demand.
The async files are also subject to this. This could also be used to
cover your tracks in the setup file, maybe?
That would super cool and addresses the above noted security state :). The
setup file is definitely useful for troubleshooting/debugging, making sure
that it contains what you had expected to be in there, but I don't want it
hanging around if I know I have a good working state. Having it be
available for a last action in a playbook sounds awesome, and I like the
idea of having ansible reach out and do a clean on demand.
Thanks Mike!
Dave