# The start of a basic check (pseudo dry run mode) mode in Ansible 1.1 **URL:** \ **Category:** Ansible Project\ **Created:** [February 4, 2013, 1:42am UTC](https://forum.ansible.com/t/the-start-of-a-basic-check-pseudo-dry-run-mode-mode-in-ansible-1-1/12288 "2013-02-04T01:42:29Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [February 4, 2013, 1:42am UTC](https://forum.ansible.com/t/the-start-of-a-basic-check-pseudo-dry-run-mode-mode-in-ansible-1-1/12288/1 "2013-02-04T01:42:29Z")
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](https://github.com/ansible/ansible/commit/fed82c2188828466202935e98e808a74903346d4) for implementation. ---
**Author:** ![James\_Nguyen](https://avatars.discourse-cdn.com/v4/letter/j/48db29/32.png) [@James\_Nguyen](https://forum.ansible.com/u/James_Nguyen)\ **Post date:** [February 7, 2013, 9:24am UTC](https://forum.ansible.com/t/the-start-of-a-basic-check-pseudo-dry-run-mode-mode-in-ansible-1-1/12288/2 "2013-02-07T09:24:51Z")
+1 I’ll be checking for the implementation in the coming days. Currently wrapping up automated stage/production deployments using ansible now which is looking friggin awesome. Now I feel comfortable having jr admins actually making deployments since they’ve managed to NOT follow directions in the past. Your initial work on this check feature is going to be extremely valuable! I know you’re against it on principles, BUT I use it all TOO often from puppet to audit changes that were never checked in and get blown away all too easily. I’ll just say again that you and ansible rock!