Does Ansible support a no-op mode to see what changes will be applied without actually applying them? I couldn’t find anything in the available documentation or did I miss something?
Regards,
Amar
Ok, so here's the deal with that.
We don't support a no op mode, and there's a pretty good reason for
it. It's my strong belief that systems that do support this aren't
providing a really high level of detail, and the results of a dry run
can also instill a misleading sense of confidence that don't
apply when you actually go to run the task.
For instance, if you restart a service, what if the configuration of
the service was wrong, and the service fails to restart, and this
breaks things further down the chain.
Ansible is very very capable of having the actions of one host depend
on the state of the other (or other variables), and dry run mode never
really takes into account side effects. In this vein, I believe it
does users a disservice.
It would technically be possible to support a comparision tool that
attempted to find all of your templates and config files, and report
which ones changed, and what tasks they might notify, but it would not
be a reasonable safeguard in production -- nor is it in any other
tool.
Another problem is that then every single module must then write a
simulated dry run mode, which I believe is unrealistic for many
modules, and clearly inaccurate in some others.
When we have things like only_if in Ansible -- which are very powerful
concepts, and register variables, tasks often depend on the results of
other tasks.
I think we're all willing to explore the "what files and templates
might change", but we're much more apt to call that "--wild-guess"
mode or something. I really feel that dry-run mode is a marketing
feature and in general, changes should always be tested
in a stage environment closely resembling production (VMware, vagrant,
etc, your choice), which is easy to set up especially if your whole
configuration is Ansible managed.
--Michael
I also think a dumb (no conditionals evaluated) recursive yaml importer/parser that pretty prints the result would be useful. so people can see what ansible will receive before ot blws up on a double colon half way through.
/me makes note to write that later
Tim Bielawa wrote:
I also think a dumb (no conditionals evaluated) recursive yaml
importer/parser that pretty prints the result would be useful. so people
can see what ansible will receive before ot blws up on a double colon half
way through./me makes note to write that later
Isn't this like what skvidal wrote for --syntax-check? (which is in 0.8)
Daniel
this is relevant to my interests
Yep.
I would very much like to see an extension of --syntax-check which is --dump-only.
It'd be nice to dump out what the complete set of tasks/handlers/etc would look like for that playbook (including its includes).
I don't have time at the moment to work on this but if anyone else wants to do it - I think it would be great.
-sv
Tim Bielawa wrote:
I also think a dumb (no conditionals evaluated) recursive yaml
importer/parser that pretty prints the result would be useful. so people
can see what ansible will receive before ot blws up on a double colon
half
way through./me makes note to write that later
Isn't this like what skvidal wrote for --syntax-check? (which is in 0.8)
Yep.
I would very much like to see an extension of --syntax-check which is
--dump-only.It'd be nice to dump out what the complete set of tasks/handlers/etc would
look like for that playbook (including its includes).I don't have time at the moment to work on this but if anyone else wants to
do it - I think it would be great.
I suspect code implications of this would have relatively large enough
impacts that I would have preferences.
Feels like something for 0.10/11 to me.
Since playbooks appear to be parsed in advance of running I was thinking it would be handy to be able to accept a playbook and print it back out.
Essentially expanding all 'includes' inline and letting you look at it as one big 'thing'.
-sv
That's exactly what I was attempting to describe here. +1 to this idea.
Is reasonable, sounds like a contrib script for now.
Listing what template files would probably have looked like for a
given host and whether they might have changed is something different
I agree that is something different. I am targetting something of relatively limited scope but, to be fair, somewhat useful.
-sv
Is reasonable, sounds like a contrib script for now.
Listing what template files would probably have looked like for a
given host and whether they might have changed is something different
+1
To add to this as another form of approach… Try running a Vagrant box with your playbook. That is what we do in my team before we commit a playbook. That will let you know what the outcome of your playbook will be.
Now that you mention it, I would like Vagrant-like capabilities using playbooks and I think this fits ansible-provisioning well.
Currently we have plugins for getting facts from external source (e.g. KVM or ESX) and boot-plugins that enable booting media for provisioning, but a third kind of plugins for creating VMs would be very useful.
The moment we have such an implementation for virtualbox we can basically do similar things using Ansible. A single playbook could create, provision and manage one or multiple VMs from start to end using a single syntax and tool.
I'd possibly consider ansible-vagrant, though the one thing I don't
care for about vagrant is it uses VirtualBox -- what I consider
one of the weakest hypervisors.
Was discussing the general idea of creation-through-config with
another user recently, and it's a little off for ansible, still,
because you need
to know what hosts it runs against.
It seems to benefit highly from the idea of being able to create
dynamic groups on the fly (hosts_created_right_now_on_this_play, in
essense) as well as to be able to
have successful creation add things to inventory in some cases.
TBD.
I'd possibly consider ansible-vagrant, though the one thing I don't
care for about vagrant is it uses VirtualBox -- what I consider
one of the weakest hypervisors.
It's all about choice. Although I don't see why we would integrate with vagrant if we can do it with modules/playbooks directly from Ansible, using the same concepts and groundworks.
My goal is to have a single playbook create, provision and install a system based on Internet resources (CentOS, Ubuntu, ...) just by adding it to the inventory. That playbook should be shareable and usable by anyone as a proof-of-concept. (only the creation part is currently missing)
Was discussing the general idea of creation-through-config with
another user recently, and it's a little off for ansible, still,
because you need to know what hosts it runs against.
Same for provisioning, we need to know that too. This information is part of inventory, just like other facts.
It seems to benefit highly from the idea of being able to create
dynamic groups on the fly (hosts_created_right_now_on_this_play, in
essense) as well as to be able to
have successful creation add things to inventory in some cases.
I cannot compute this block. I lack context/semantics, what are we talking about ?
For provisioning we disable facts-gathering until the system has been provisioned, the very first task directed to the system will continue facts-gathering.
We’re just getting started with ansible, so this may be a beginner’s mistake, but we are looking very seriously at doing a dry-run fork. I think I understand the philosophical arguments against it, but we find the prospect of running an update to a config file without verifying the changes we expect to see too hard to stomach. So, our proposal would look something like:
- Update ansible-playbook to take the “–dry-run” flag
- Update ansible-playbook to exit if “–dry-run” is active and the playbook contains modules without a dry-run option
- Update the modules we plan to use the most (user, file, copy, and template, to start) to accept the dry-run flag
- Update the modules to, upon receiving the dry-run flag, do the same tests they currently do, output, and exit
Is this totally insane? It doesn’t feel that way, but the consensus seems to be the opposite, and I’m trying to figure out what I missed.
-Chris
I have a script that can generate the template files locally (I was
writing jinja/yaml templating for my own system when I discovered
ansible which worked the same, only better).
Also, you can have a playbook that just writes the config file to a
different path (even local) to compare.
you really don't need --dry-run for that.
I would *almost* be interested in changes that only compare template
and file differences via md5sums but am skeptical to what it does to
the codebase.
I am certaintly NOT interested in seeing dry-run modifications to any
server side modules (yum, etc), though if it only affects things
client side, that's not so bad -- but also not so useful.
However, because of the various reasons config files change (even
because of what package installers may do), the results are always
going to be a lie, and a source of false information.
Not just in ansible, in anywhere. The whole flag is basically a "I
guess these things will change". Once you insert other
conditionals, indeed a core facet of ansible, and derived facts that
could be changed by other evaluations, it's even more fraudulent.
So... really... I don't see the point in this. It's going to get
people burned.
I would strongly encourage you not to attempt to fork the community.