No-op or dry-run mode ?

[Amar Sanakal]

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

[Michael DeHaan]

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

> --
>
>

[Tim Bielawa]

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

--

[Daniel Hokka Zakrisson]

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

[Tim Bielawa]

this is relevant to my interests

--

[Michael DeHaan]

On Mon, Oct 22, 2012 at 9:27 AM, Daniel Hokka Zakrisson
<dan...@hozac.com> wrote:
> 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.

[Seth Vidal]

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

[Michael DeHaan]

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.

>
> -sv
>
> --
>
>

[Seth Vidal]

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

[Tim Bielawa]

That's exactly what I was attempting to describe here. +1 to this idea.

--
--Tim Bielawa
http://lnx.cx

[Michael DeHaan]

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
:)

> --
>
>

[Seth Vidal]

On Mon, 22 Oct 2012, Michael DeHaan wrote:

> 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

[Michael DeHaan]

On Mon, Oct 22, 2012 at 5:49 PM, Seth Vidal <skv...@fedoraproject.org> wrote:
>
>
>
> On Mon, 22 Oct 2012, Michael DeHaan wrote:
>
>> 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

>>
>
> I agree that is something different. I am targetting something of relatively
> limited scope but, to be fair, somewhat useful.
>
> -sv
>

> --
>
>

[Dylan Silva]

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. 

--

Dylan

--

[Dag Wieers]

On Mon, 22 Oct 2012, Dylan Silva wrote:

> 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.

--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, in...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

[Michael DeHaan]

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.

> --
>
>

[Dag Wieers]

On Tue, 23 Oct 2012, Michael DeHaan wrote:

> 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.

[Chris Peters]

 
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:

1. Update ansible-playbook to take the "--dry-run" flag
2. Update ansible-playbook to exit if "--dry-run" is active and the playbook contains modules without a dry-run option
3. Update the modules we plan to use the most (user, file, copy, and template, to start) to accept the dry-run flag
4. 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

[Brian Coca]

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.

--
Brian Coca
Stultorum infinitus est numerus
0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001
Pedo mellon a minno

[Michael DeHaan]

On Fri, Jan 18, 2013 at 9:10 PM, Chris Peters <ch...@expensify.com> wrote:
> On Monday, October 22, 2012 2:52:15 PM UTC-7, Michael DeHaan wrote:
>>
>> On Mon, Oct 22, 2012 at 5:49 PM, Seth Vidal <skv...@fedoraproject.org>
>> wrote:
>> >
>> >
>> >
>> > On Mon, 22 Oct 2012, Michael DeHaan wrote:
>> >
>> >> 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
>>
>> >>
>> >
>> > I agree that is something different. I am targetting something of
>> > relatively
>> > limited scope but, to be fair, somewhat useful.
>> >
>> > -sv
>> >
>> > --
>> >
>> >
>
>
> 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:

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.

[Michael DeHaan]

Client/server is confusing here, I meant server side modules are
something to explore.

Don't explore modifying anything in library.

[Chris Peters]

Correct me if I'm wrong, but it sounds like we might be approaching this with a different set of assumptions. For any reasonably complex, or multi-task playbook, trying to establish the future "true state of the system" would be a fool's errand. If that's what you're objecting to, I totally agree. What we're interested in doing, is, for small, relatively atomic changes, have a switch that says "just tell us what you're planning to do".  For example, for a templated deploy of a config file, show a diff, but do nothing. For missing or out-of-date packages, just output the package and version that is intended to be installed, etc. That said, the diff example might return wholly inaccurate info, depending on if it ran before the package install. (which I think was one of your points, as well)

Fortunately, after kicking it around the office for awhile, we realized that most of the logic can just go into the playbook, and doesn't need to be complicated by creating a fork. We'll probably just do our own "check to see if a package is installed" and "do a diff of what would be pushed" (by deploying a temporary copy and then running diff, great idea, Brian) modules, and build them into our playbooks.

-Chris

[James Nguyễn]

I'm in support of at *least* a minimalist approach to a dry run switch/param. I want to at least be able to see what config files managed directly by file/template/copy are going to be modified if not also diff'ed so I can confirm those changes are up to date. When you work in an ideal environment and no one has access to your hosts, this might not be useful, but in a multi-admin/user environment I'd assume the worst.

Case in point with us developers have access to prod. They had to put in a really quick hotfix to a config and forgets to also update ansible/puppet. When release day comes that fix is reverted and bugs are reintroduced. My sanity check during deployment currently with puppet is to use their --noop param so I can first see the changes coming in are to be expected before I blindly apply anything. This has saved my tush quiet a number of times.

This doesn't have to be an all fancy solution or anything, but at least have a dry-run option so you can display results of changes as it already does now, but do not apply anything if requested.

[Michael DeHaan]

So after a bit of a break adding core things, this actually hits
pretty good timing now.

I'll very likely be added a --check mode in the coming weeks that will
assuredly support files, templates, and hopefully also
packages/services.

Stay tuned!

[Brian Coca]

until then, use the backup option, it is a life saver for rollbacks
(but now you also need a clean_backups.yml).

> --

[Michael DeHaan]

On Fri, Jan 25, 2013 at 9:51 AM, Brian Coca <bria...@gmail.com> wrote:
> until then, use the backup option, it is a life saver for rollbacks
> (but now you also need a clean_backups.yml).

Yep, I generally think we should make the backup_local code by default
(maybe unless so configured) keep N backups.

(For those that didn't know, backup=yes can be added to the various
file/template options and it saves filename with the timestamp added
to the end)

[James Nguyễn]

I like the backup option, but it doesn't cover the use case where my playbook swaps out the working config and then restarts the service because of a notify handler. At that point you're wondering why I don't copy it to a staging area before applying, but then that takes away from the simplicity of configuration management. In the end your implementation of --check will be much cleaner and more simple.

I've honestly used it so much that I've replied on it just for sanity checks when something goes wrong in production and developers try to point fingers. I just run a puppet --noop and redirect the blame right back. It's just a great insurance measure.

[Michael DeHaan]

Cool.

I am going to start on this today, though we'll see if I violate my
own code freeze and merge it for release or not :)

> --
>
>

[James Nguyễn]

+1 on violating that code freeze. ;)

Really appreciate your work BTW!

[Константин Вишнивецкий]

Hi, Michael

I totally argee with you. Today I had in incednet which show how much truth is in you words.

I have a playbook, which install a set of pacjages and then perform few tasks to run and enable services, which were installed earlie, in previous tasks.
So, in "dry run" mode task, enabling services would fail, because ansble will try to check actual state of services in actual, real OS, BUT, there is no packages installed yet and no init scripts for services.
In "run for real" mode task would not fail, cause all needed stuff will be installed "for real" in actual system.

понедельник, 22 октября 2012 г., 18:52:51 UTC+7 пользователь Michael DeHaan написал: