Closed MatthiasGabriel closed 7 years ago
Hi @MatthiasGabriel - thanks for reporting this!
I've had the same issues with IOS-XR in the past. As all requests are executed over the same session, the commands will overlap. All we can do with IOS/IOS-XE is screen scarping, so we don't have any mechanism similar to NETCONF able to assign an unique request ID and then identify.
The solution I found in XR is a simple and straightforward mutex lock-unlock mechanism. Doing so, each request is queued and served when the channel is "free" again. The whole code necessary is in https://github.com/fooelisa/pyiosxr/blob/master/pyIOSXR/iosxr.py#L189-L199. Ideally we should have had a way to uniquely identify each request, but the device unfortunately does not provide any feature for this. So, it won't be the most optimal solution, but I can say that it really did the job for XR, at least.
So I will ask @ktbyers what he thinks about that.
Cheers, Mircea
Yes, that should be fine.
I assume the user would just manually acquire the lock (i.e. the default would be no locking).
The configuration lock will not be touched in that case - it's just a naming coincidence. All it does is sort of "virtual" lock per command, so two or more requests over the same SSH session won't overlap. So it will preserve the current behaviour. I have an IOS device to test next week and I can give it a try and see.
@mirceaulinic is that because salt is reusing the same ssh connection? Calling getters
over different ssh connections should be fine.
Yes, that's correct @dbarrosop - they are using the same SSH connection.
Disclaimer: Now I am talking out loud mostly out of curiosity and ignorance.
Could the minion just fork itself for each "set of queries"? On minion creation you just save the data necessary to create a new connection and everytime salt sends a query to the minion you just fork a process, create a new instance of the object, execute the query/queries and close it. This would allow you to run parallel queries to the same device (I don't know if minions have some limitations that wouldn't allow you to do this). This combined with "ssh control connections" should give some nice extra functionality without the extra penalty of opening a new connection.
Unfortunately no, thats not how proxy minions work today. They've been designed to keep the connection always alive, to be similar to the regular minions. However, the main difference is that regular minions don't use SSH as transport, so our case is slightly different. Anyway, going full parallel should not be a limitation IMHO and we should address that.
Hi @MatthiasGabriel - netmiko 1.3.0 has been released and includes the changes from https://github.com/ktbyers/netmiko/pull/407. Can you upgrade and confirm it works now? For the moment I am going to close this issue, but feel free to reopen if still not fixed.
Description of Issue/Question
It seems that napalm-ios doesn't handle multiple parallel requests correctly, while other drivers like junos, iosxr or eos are capable of doing this.
Did you follow the steps from https://github.com/napalm-automation/napalm#faq
Setup
/etc/salt/proxy
napalm-ios version
(Paste verbatim output from
pip freeze | grep napalm-ios
between quotes below)IOS version
(Paste verbatim output from
show version
between quotes below)Steps to Reproduce the Issue
When I execute multiple salt commands simultaneously they sometimes / most of the time disturb each other. It's possible that you can't reproduce this Issue with your first try. Also the given result is not always the same. Sometimes they just don't deliver the expected output, sometimes there is a traceback.
To reproduce just execute two tasks in parallel e.g.
Error Traceback
(Paste the complete traceback of the exception between quotes below) Sadly the "Error Traceback" is not always the same. I think it depends on the timing... I've collected some of the recent tracebacks and results I've got. If you need more just ask :)