I recall reading somewhere the reason why Scotty from the original
Star Trek always said was something was impossible was it would look
more impressive when he got it done.
I still disagree with dry run in MANY cases, and you should never
think in anyone's system this is going to tell you where a rollout
will work in production -- packages can fail, scripts can fail,
services might not start, the network is not always reliable, etc.
Still, people have wanted a way to tell if any templates or basic
things might change on a remote system. I have the groundwork of this
started now on the development branch and any developers interested in
understanding it should look at the relevant commits.
In short, I've implemented the start of basic --check mode to
/usr/bin/ansible and /usr/bin/ansible-pull.
Modules must opt in to say they support a check module or not. So
far, only 'template', 'copy', and the underlying code for file (but
not the module itself) to do this, and I'm not even sure this is 100%
correct in those yet. Work in progress. Note that I also marked
setup and ping as modules that support check mode. Why? So they
don't show up as skipped and actually do run remotely, and in the case
of setup, so you can get as many variables back as possible (as you
may need them)
In this case, the file module will tell if it is going to change
something, and then it returns 'changed'. The copy module notices
when md5 sums or file attributes would need to change, and so
does the template module.
I also fixed what I think was a problem with the template module in
that it would always transfer template files (non-idempotently? The
horror!) and now it will check the md5sum first.
The consequence is if no changes are being made, it's about as fast,
and if they are, there's an extra md5sum op. I think that's ok.
We are NOT done yet.
We need to make at minimum the service, package, and actual file
module all compliant by adding 'supports_check_mode' and appropriate
logic on all platforms.
What won't work? If you are making use of conditionals, the results
coming back from commands may be different. Whether this works or
does not work for you, therefore, is somewhat up in the air... the
whole point about ansbile is for it to be an orchestration engine, and
to predict what it is doing in advance on a system (or a collection of
them) via pure simulation is clearly just a guess.
That all being said I hope everyone wanting this feature are excited
about this development. We have open issues to at minimum teach apt,
yum, service and file how to understand --check before I'd consider
this field worthy, but everyone should take a look now and see what
you think.
I have an additional idea of making template and file be able to
output unified diffs when they make changes, but I think that should
be controlled by a /seperate/ flag and not this one, as it could spam
your terminal pretty bad. Would be useful and neat though.
Take a look at https://github.com/ansible/ansible/commit/fed82c2188828466202935e98e808a74903346d4
for implementation.