IOS-XR: if a commit fails, read_until_prompt waits forever about netdev

[selfuryon]

Thank you for your interest to this library!
I really didn't test carefully IOS XR class because I haven't it in my work. I can divide my thoughts into 2 points:

1. I want to make timeout for operation for a long time :) I want to add default timer to all read operations in all classes for better controlling the flow. And I have the stimulus to do it right now :) I think that it should raise timeout exception.
2. In this particular situation, it's a normal operation and we should make changes in function for normal processing this variant.

Firstly, we should check the output for the string "Failed to commit" and raise the "Failed to commit" exception. And we also should check "Uncommitted changes found" after "end" command.

Right now we have function with these parameters async def send_config_set(self, config_commands=None, with_commit=True, commit_comment='', exit_config_mode=True). So we can have different situations:

• with_commit=True - All changes will be commited. If not - we will get "Failed to commit" exception
• with_commit=False and exit_config_mode=False. Nothing special, user should make decision himself
• with_commit=False and exit_config_mode=True - I think we should always exit from config mode without any changes. In this situation we should check the output for "Uncommitted changes found" string by using special function for this purpose: _read_until_prompt_or_pattern. We should override exit_config_mode in IOS XR class or maybe change this function in IOS class.

I can make these changes in this week, but if you really want to help me and make changes yourself - it will be really great!! You can pm me in telegram or slack and I can help you make PR for it.

[cjrh]

I'm happy to help.

I will create a PR, and then the first thing I'll do is create a test that demonstrates the issue. Then we can discuss the test. Then I will add code to resolve the problem, which will include the handling you've discussed above.

Sound good?

[selfuryon]

Yes, it will be amazing! I will wait for the PR!

[cjrh]

Quick note to say I have not forgotten about this issue, but I've been extremely busy recently.

[selfuryon]

Hello, @cjrh!
I have just pushed new code to IOS XR class. Right now it works like this:

• with_commit=True - All changes will be commited. If not - we will get CommitError exception
• with_commit=False and exit_config_mode=False. Nothing special, user should make decision himself
• with_commit=False and exit_config_mode=True - exit from config without any changes and commits

For taking this behavior I made these changes master...develop#diff-c089f96ea63362ebd55df599d9d7c153. The main:

• I change cleanup function for properly session termination. In all sessions, we should clear all unsaved changes, so I simply write "abort" to channel. It's useful when we get Exception because we are using an async context manager which always runs cleanup function.
• I changed exit_config_mode function for properly working with an unsaved date when we have this condition "with_commit=False and exit_config_mode=True".

Can you test it in your environment? After that, I will release it in master branch :)

[selfuryon]

Forgot! I also added timeout params for managing timeout in all async operations :) You can use it only in init. The default timeout is 15 seconds:

def __init__(self, host=u'', username=u'', password=u'', port=22, device_type=u'', known_hosts=None, 
local_addr=None, client_keys=None, passphrase=None, timeout=15, loop=None):

I thought about adding timeout exactly to operations (send_config_set and send_command) but I don't know if it's really necessary. Do you need this?

[cjrh]

@selfuryon Thanks! I will have a look towards the middle or end of this week.

[selfuryon]

@cjrh Hello! Did you test new code? :)

[cjrh]

Sadly, I have not tested it yet. I did the workaround we discussed, where I made a subclass of the XR class and so far that has worked very well. sorry!

[spdkils]

This same stuck can happen on IOS.
I suspect the find_base_prompt() gets stuck for a similar reason...
Say you have a switch that has an automatic vty command, and you forget to issue the proper command....

autocommand who

but they forgot the...
autocommand-options nohangup

Well, now you connect, get logged in, and before the prompt ever appears, you're disconnected.

Well now you're stuck, you're stuck at the find_base_prompt() forever...