"compare" mode is added.

[ymitsos]

Using the latter, one can compare the generated configuration changes against the running configuration. Changes are not staged to the equipment. Similar to "show | compare" in Juniper edit mode.

[vnitinv]

@ymitsos Hi Yannis, we have a reserved keyword "mode" in PyEZ which we will be using in our ansible modules
#162
Can you check if you use any other keyword in place of "mode"?

[ymitsos]

substituted with "commit_mode"

[stacywsmith]

@ymitsos Can you explain the benefit of this pull request vs. simply running the module in check mode?

With your pull request, it appears "commit_mode: 'check'" would be exactly equivalent to running the module in check mode. In addition, it appears the only functional difference between "commit_mode: 'check'" and "commit_mode: 'compare'" would be that the latter does not perform the "commit check". In all cases the configuration diff file is produced.

I simply don't see any benefit from this pull request. Especially with Ansible >= 2.2 where individual tasks can be run in check mode.
http://docs.ansible.com/ansible/playbooks_checkmode.html#enabling-or-disabling-check-mode-for-tasks

[ymitsos]

indeed, with commit_mode set to check you gain the same behaviour as with switch -C; however, when you have a complex network or many playbooks that need to be orchestrated and combined together to produce a result, you may prefer to control the running mode inside the playbook to avoid unpleasant surprises if you omit the "-C" in command line in one run. Secondly, there are cases where you need to run a big job with some tasks that are not harmful (e.g. fetch data from other sources like databases, WHOIS server and produce local YAML files for further processing) and those tasks should not be run in check mode, while other task should that interact with network equipment should be run in check mode.

Furthermore, "compare" is different to "check". In the former you only get the diffs while in the latter you perform a commit-check that is a task requiring CPU resources and elevated access privileges.

Concluding, this patch comes mainly from our need to run complex playbooks that produce the entire configuration of all network gear (routers, switches, data center switches). The playbooks run in defined intervals and we need to have good flexibility of the changes submitted to production boxes.

[stacywsmith]

you may prefer to control the running mode inside the playbook to avoid unpleasant surprises if you omit the "-C" in command line in one run.

Indeed, that is the capability supported by Ansible in 2.2 for all tasks:
http://docs.ansible.com/ansible/playbooks_checkmode.html#enabling-or-disabling-check-mode-for-tasks

I understand the desire to skip the commit check. Would that be better accomplished by adding a commit_check boolean argument which defaulted to True (the current behavior)?

[stacywsmith]

The change looks good. If you can update to address the conflicts, I will merge ASAP.