feat: PUC-785: crud ucvni-group range on network-segment-range events

[haseebsyed12]

tested end to end workflow

[mfencik]

IMHO, the python code should be refactored as those long functions are not readable and I don't see any tests for those too. Let's try to keep our code clean and tested as much as possible, good practices can be found at https://refactoring.guru/refactoring

[skrobul]

Now that https://github.com/RSS-Engineering/undercloud-rackspace/pull/415 has landed, please rework this to use pynautobot to avoid duplication

[skrobul]

this code still has multiple references to the requests library. There are few places where the code looks for RequestException, while the pynautobot documentation states that the unhappy path raises Nautobot specific exceptions. Could you please verify which ones are actually used and adjust if needed?

[haseebsyed12]

@skrobul : here I added this to capture nautobot service down scenario. Please suggest if this can be handled using pynautobot exception. I did not find any such.

[skrobul]

Correct me if I'm wrong but this except block is essentially a dead code that can never be reached. Here is why:

1. Your code (correctly) initializes Nautobot object providing URL, token and logger and accepting other defaults.
2. Nautobot looks for a provided session and if one isn't, it creates one by calling pynautobot.api.
3. When pynautobot.api initializes, it creates a requests.Session(), again using requests library defaults. Unfortunately, these defaults are stupid. All of the requests created with a default session do not time out and hang around forever.

In summary, with current setup, I don't think the ConnectTimeout will ever be raised, but if you managed to get this raised I'd be interested to see the code to replicate this.

Now, in terms of solutions here - I think it would be reasonable to:

• move the Nautobot related code to nautobot.py
• once that's done, look into how we can fix the Connection Timeout handling on connections to Nautobot, not only for this call but also for other ones in nautobot.py which seem to suffer from the same problem

[haseebsyed12]

I tested connection timeout in my local without connecting to Appgate and I am able to catch requests.exceptions.ConnectTimeout.

Regarding setting timeout I followed this documentation. But in my above scenario this is not useful because it's only added after the api() call has already returned in nautobot.py.

def api_session(self, url: str, token: str) -> NautobotApi:
       api = pynautobot.api(url, token=token)
       api.http_session.mount(api.base_url, TimeoutHTTPAdapter())
       return api

What do you suggest about my test without connecting to Appgate ?

[skrobul]

Turns out I was wrong. If you ignore the documentation linked above, the connection attempts do not actually hang forever anymore and the ConnectTimeout is handled on the lower level and defaults to socket's default timeout.

After further testing on my machine, the simulated timeout happened after about 2 minutes and 15 seconds

>>> try:
...   print(datetime.now())
...   nb.dcim.devices.get('52a36d73-2e43-4ba1-b64a-9b99aa6b862c')
... finally:
...   print(datetime.now())
... 
2025-04-15 15:42:58.739109
2025-04-15 15:45:13.121909

The same test on @haseebsyed12 took just 75 seconds. Looking at the urllib3 source code this might be OS dependent:

In conclusion, I think we can stick to the defaults as they are and only implement the TimeoutHTTPAdapter when we need to change them to a specific value. My primary concern was around having the timeout potentially set to infinity which clearly isn't the case, so my comment can be disregarded and no further changes are needed here.