Design spec for Junos and IOS-XR on commit/confirm/rollback about netmiko

[ktbyers]

Other references issues, issue #57 (commit confirm).

See issue #34 for reference to messages for uncommited changed.

See issue #8 (IOS-XR rollback)

See issue #7 Commit on IOS-XR

[supertylerc]

There is also an IOS XR and Junos configure exclusive to lock the candidate config from other users.

[ktbyers]

commit() is currently a separate method both for Juniper and IOS-XR.

For Juniper it has a delay_factor attribute which defaults to 10 (give sufficient time for commit to complete.

It is also used by send_config_set(). Note, send_config_set() has no way to modify the delay_factor.

IOS-XR currently has no delay_factor.

[ktbyers]

commit() method parameters should have:

JUNIPER

delay_factor (integer)
confirm (boolean)
confirm_delay (how many minutes to wait for confirm, defaults to 10) -- need to verify what default is for IOX-XR
check (boolean), defaults to False, has precedence over confirm (i.e. if check = True) then confirm is N/A.
comment Message to commit log

Do we need 'commit at ?' -- I would say probably not as a person could always manually do something via send_command(), if needed (open to discussion on this)

Should send_config_set() explicitly support commit() calling or should these be separate actions (send_config_set() and then commit() ). If send_config_set() calls commit() then commit arguments must be able to be passed into send_config_set.

[supertylerc]

I think send_config_set() should not call commit(). "Do one thing and do it well." IMHO (and feel free to disagree since you're the creator/maintainer :)), this should be a framework around which solutions are built. Trying to do too much magic overcomplicates said framework and potentially reduces its flexibility for building tools.

[supertylerc]

Also, one issue to be aware of is what happens if someone calls it like this:

commit(delay_factor=10, confirm_delay=5)

confirm will need to be set to True any time confirm_delay is used but check is not. Which means confirm_delay cannot have a default value (it must be None), or it will automatically set confirm = True. There are a few possibilities. One is to remove confirm, default confirm_delay to None, and use if confirm_delay is not None: to flip the bit on confirm. The other option is to continue to use confirm and confirm_delay in the method parameters, and raise an exception whenever confirm_delay != 10 and confirm = False.

[ktbyers]

I agree on the send_config_set(), commit should not be a part of this. Besides your "do one thing well statement" which I agree with. It also will really complicate the passing of arguments for commit.

[ktbyers]

commit(delay_factor=10, confirm_delay=5) --> should generate an exception

So confirm_delay will need to default to None (good point on this). We can then use the platform's default confirm_delay (i.e. only pass in a confirm_delay if the end-user specified an argument). This is a better way to do it.

commit(confirm=True, delay_factor=10) --> send to juniper 'commit confirmed'

commit(confirm=True, confirm_delay=5, delay_factor=10) --> send to Juniper 'commit confirmed 5'

Let me know if you see issues with this.

[supertylerc]

Looks good to me.

[ktbyers]

Juniper is done. Still need to do IOS-XR.

[ktbyers]

Closing this issue. See issue #89 for IOS-XR.