-
Notifications
You must be signed in to change notification settings - Fork 239
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple tasks on one host at the same time in threads #325
Comments
This is a bit more complex than this. You have to be able to pass different arguments to different tasks. Otherwise, you'd be running the same exact thing N times in parallel. So basically it requires a new entire method.
Why is that necessary? Overall I feel skeptical about this and my vote would be to keep it on hold until we have more use cases to see (a) if it's really needed and (b) what is it that people actually wants to do and why. In the meantime, a simple workaround for this is as simple as just "hacking" your inventory a little:
|
Yes, I agree with David here i.e. let's punt this issue 6 months or 12 months down the road and see how important of a use case it is. I am definitely concerned about the added complexity it will entail and whether that complexity is worth it. |
I agree with you all :) |
yeah, that sounds like a great idea. |
The usecase that I would like to use something like this for would be operations that take a significant amount of time to run, but do not risk pegging the remote device's CPU. For example, I use nornir to run a post-change data collection/validation runbook, and in that runbook, I use seed devices throughout the network and run traceroutes to specific hosts in the data centers to determine if the path to the DC's has changed. The traceroutes take a significant amount of time to complete, and we are running them to about 16 different hosts from each seed device. We can use parallelism between each seed device, but since some of the traces can take a minute or so to complete, the runbook takes 10-13 minutes to complete all of its tasks. If we could run 8 or so parallel threads, that would reduce the traces from taking 9 minutes down to 2 minutes. The runbook is intended to give an engineer feedback on their change and whether they should roll back, so the faster we can return results to the engineer, the faster we can isolate outages or issues after the change. For me, I could use David's inventory hack, but if the inventory source was something other than a simple inventory file, thisb could be problematic, unless I use the new Inventory methods to dynamically generate the new groups, but the feature would be useful for this purpose. |
FWIW I am thinking in looking into this as part of the asyncio interface. |
Ok, I think I have an example of how this may work for you:
Don't bother too much with the changes in the API, this is not going to happen anytime soon (might not even happen at all), but I am playing with several ideas that may lead to a cleaner core. |
Hi guys, First post here, loving Nornir so far! I have run into a case, where I would like to configure all 48 interfaces in a C9300, where some of them have to be enabled and others shut. I am currently iterating through each interface from Netbox and using netmiko_send_config to send the config. This takes around 2-3 minutes. I know that I can send the config for all 48 interfaces as a single string seperated by '\n', however, this won't allow to track the changes and task status for each interface. If the task fails, then it's impossible to track which part of the configuration failed in the string. Is there a better way? |
@uthman-s this is off-topic for this issue. I would recommend creating a separate thread on our forum: https://nornir.discourse.group/ |
Another option is to use You will still potentially have a bit of an issue of tracking where it failed however (though NAPALM should auto rollback on failure so at least it should return the device to its original state). |
This issue was created to discuss the possibility of running multiple tasks at the same time on one host in threads.
There are two things that are needed to make this work:
nr.run
could accept a tuple of args instead of a single tasknapalm
connection, the second task should open a newnapalm-2
connection and use that.The text was updated successfully, but these errors were encountered: