Add a parameter to only do a commit check

[XioNoX]

This is useful when doing first a "commit confirm" followed directly by a "commit check".
That way, if the commit breaks connectivity to the device, the configuration rollbacks, if there is still connectivity the commit check is faster than a full commit and doesn't trigger configuration archival, etc..

Example:

- name: "Do a commit confirmed 2 or commit check"
  junos_install_config:
    host={{ inventory_hostname }}
    port=22
    file="{{ assembled_conf }}"
    overwrite=false
    replace=true
    diffs_file="{{ logs_dir }}/{{ inventory_hostname }}.diff"
    logfile="{{ logs_dir }}/{{ inventory_hostname }}.log"
    timeout="300"
    comment="Ansible"
    confirm="2"
  register: push_result

- name: "commit check to confirm the previous commit"
  junos_commit:
   host={{ inventory_hostname }}
   check=true
  when: not check_mode and push_result.changed

[vnitinv]

@XioNoX If I am not wrong if we can provide --check option on command line while running playbook. This would take care of commit check.
Refer:
http://docs.ansible.com/ansible/playbooks_checkmode.html
https://github.com/Juniper/ansible-junos-stdlib/blob/master/library/junos_commit#L162-L164
Can you give a try to the option.

[XioNoX]

@vnitinv The issue if I do that with the example tasks above is that "junos_install_config" will also be ran as --check, and thus will not commit anything.

[chris0]

I'd look at working this into junos_install_config, instead. I have a PyEZ-based script that does a commit-confirm, followed by a probe after an arbitrary sleep, and a commit-check if still connected.

The applicability of running this as a separate play is rather narrow. Hundreds of junos_install_config jobs could have their commit-confirm timeout and rollback before the commit-check is ever done.

[mortalius]

+1
I need it too, but in a bit different scenario.
Despite of extreme 'commit confirm' usefullness I prefer to double check what i am commiting.
I am making interactive playbook, that runs without check mode and makes all required checks in one play. It first shows me diff while doing commit check and after I visually review and accept changes, it makes commit.

[XioNoX]

@vnitinv ping?

[XioNoX]

@vnitinv could that PR have some attention?
thanks

[vnitinv]

@XioNoX Will look into this

@stacywsmith Can you please look into this pull request and review the same.

[stacywsmith]

@XioNoX

Sorry, but I'm trying to wrap my head around how this is useful.

In your example, you modify the config using junos_install_config. You specify the confirm="2" argument which will role the configuration back in 2 minutes if not confirmed.

You then execute junos_commit with the proposed check=true argument. This would cause a commit check to be executed instead of a commit.

Yes, the name: "commit check to confirm the previous commit" task would fail if the previous task caused the device to become unreachable, but I don't see the benefit.

I see two issues:

1. A commit check does not confirm a commit confirmed 2. Without an additional commit the configuration will still be rolled back in 2 minutes.
2. Performing a commit check in this case will always succeed as long as the device is still reachable. Otherwise, the previous commit confirm 2 would not have succeeded.

Maybe I'm still missing something about your change. If so, please try to enlighten me. ;-)

[stacywsmith]

@mortalius I believe what your requesting is slightly different. It's a change to junos_install_config and not junos_commit. I believe what your requesting (the ability to simply load a config and get the diff of the load without committing) is implemented by #163. Can you please check #163 and see if it satisfies your requirement?

[stacywsmith]

A commit check does not confirm a commit confirmed 2. Without an additional commit the configuration will still be rolled back in 2 minutes.

Doh! My apologies! I now see this is an incorrect statement. A commit check DOES indeed confirm a previous commit confirmed 2! (Learned something new today.)

I now see the light (and the benefit of your pull request).

[stacywsmith]

Just requesting an addition to the comment to better explain the behavior.

[stacywsmith]

Since the Junos behavior was not obvious to me, can you please add a line or two to this comment explaining why this is useful? Something like:

Both a commit and a commit check can be used to confirm a previous commit confirmed <min>. However, a commit check confirms the previous commit without performing an actual commit and modifying the configuration rollback history.

[XioNoX]

Thanks for the feedback, description updated.