03-31-2021 09:06 AM
Hi,
I'm testing NSO commit queues using NSO 4.7. The feature seems to work as expected via CLI. I have a netsim device which I can push service configuration to. I shut down this device in order to test commit queue behaviour via CLI, as follows:
1) Enable NSO commit queue behaviour globally, with the following settings:
SYNC
TIMEOUT = 10s
ROLLBACK-ON-ERROR
2) Create some service configuration (i have a simple service that configures a device interface).
3) Commit. NSO hangs for 10s and then returns with the following message:
commit-queue { id 1617202306780 status timeout }
And I see the transaction hanging out in the commit queue:
admin@ncs# show devices commit-queue WAITING TRANSIENT IS ID TAG AGE STATUS DEVICES FOR ERRORS COMPLETED ATOMIC NAME REASON NODE ID -------------------------------------------------------------------------------------------------------------------- 1617202306780 - 21 executing [ asr9001b ] - [ asr9001b ] - true
If i delete the queue item NSO rolls back the changes to CDB. All good.
Now if i create the same service via RESTCONF I get a different behaviour.
NSO responds immediately with the following:
<commit-queue xmlns='http://tail-f.com/ns/rest'> <id>1617202357296</id> <status>completed</status> </commit-queue>
So it doesn't hang for 10s and status is `completed` rather than timed out.
Also. there is no item in the commit queue, although changes have been made to CDB for the service config.
So - my question is what's going here with the RESTCONF interface? Is there something else I need to switch on in NSO to get the same behaviour as per CLI?
Many thanks
Solved! Go to Solution.
04-01-2021 07:56 AM
Hi,
yes, looks like i made a mistake somewhere when testing restconf. Probably i already had some config on the device from previous calls on the service.
I tried it again - first with a dry-run from the RESTCONF api in order to validate the device will be changed -
<dryrun-result xmlns='http://tail-f.com/ns/rest/dryrun'> <result-xml> <local-node> <data> <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>asr9001b</name> <config> <interface xmlns="http://tail-f.com/ned/cisco-ios-xr"> <GigabitEthernet> <id>0/1</id> <description>INTERFACE DESCRIPTION PLACEHOLDER</description> <mtu>1514</mtu> <load-interval>30</load-interval> </GigabitEthernet> </interface> </config> </device> </devices> <services xmlns="http://tail-f.com/ns/ncs"> <attachment-tagged-physical-int xmlns="urn:refinitiv:attachment-tagged-physical-int"> <attachment-name>my-int</attachment-name> <pe-name>asr9001b</pe-name> <interface-type>GigabitEthernet</interface-type> <interface-id>0/1</interface-id> <attachment-bandwidth>1</attachment-bandwidth> </attachment-tagged-physical-int> </services> </data> </local-node> </result-xml> </dryrun-result>
...And then, when commiting the change, my api call does indeed hang for 10s and then i do indeed see the correct response:
<commit-queue xmlns='http://tail-f.com/ns/rest'> <id>1617288642727</id> <status>timeout</status> </commit-queue>
And there's queue item:
System message at 2021-04-01 14:50:42... Commit performed by admin via http using rest. admin@ncs# *** ALARM connection-failure: Failed to connect to device asr9001b: connection refused: NEDCOM CONNECT: Connection refused (Connection refused) in new state admin@ncs# show devices commit-queue WAITING TRANSIENT IS ID TAG AGE STATUS DEVICES FOR ERRORS COMPLETED ATOMIC NAME REASON NODE ID -------------------------------------------------------------------------------------------------------------------- 1617288642727 - 45 executing [ asr9001b ] - [ asr9001b ] - true admin@ncs#
So looks like it was my setup throwing me off.
Thanks for pointing me in the right direction.
04-01-2021 05:49 AM - edited 04-01-2021 05:49 AM
I tried on NSO 5.1 for both the legacy REST API and RESTCONF,
and also on the current development HEAD for RESTCONF; I could
not reproduce this behaviour. I.e. there is a 10 second wait for the
before the commit-queue timeout failure response.
Could you test if this behaviour is reproducible on an NSO 5.x release?
Note that I have not tested on NSO 4.7.
04-01-2021 06:05 AM
That's helpful, thanks, and would seem to point at a potential bug then I guess in 4.7
We're due an upgrade to NSO 5. I will re-test once we've done that.
04-01-2021 06:35 AM - edited 04-01-2021 06:36 AM
My fellow collegue tested on NSO 4.7 and it works there as well.
However, we didn't try with a service just device config data.
Does the change only result in service meta-data changes?
That could explain the behaviour. Try changing the service
configuration, then perform a dry-run before commit and
see what the change would be.
04-01-2021 07:56 AM
Hi,
yes, looks like i made a mistake somewhere when testing restconf. Probably i already had some config on the device from previous calls on the service.
I tried it again - first with a dry-run from the RESTCONF api in order to validate the device will be changed -
<dryrun-result xmlns='http://tail-f.com/ns/rest/dryrun'> <result-xml> <local-node> <data> <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>asr9001b</name> <config> <interface xmlns="http://tail-f.com/ned/cisco-ios-xr"> <GigabitEthernet> <id>0/1</id> <description>INTERFACE DESCRIPTION PLACEHOLDER</description> <mtu>1514</mtu> <load-interval>30</load-interval> </GigabitEthernet> </interface> </config> </device> </devices> <services xmlns="http://tail-f.com/ns/ncs"> <attachment-tagged-physical-int xmlns="urn:refinitiv:attachment-tagged-physical-int"> <attachment-name>my-int</attachment-name> <pe-name>asr9001b</pe-name> <interface-type>GigabitEthernet</interface-type> <interface-id>0/1</interface-id> <attachment-bandwidth>1</attachment-bandwidth> </attachment-tagged-physical-int> </services> </data> </local-node> </result-xml> </dryrun-result>
...And then, when commiting the change, my api call does indeed hang for 10s and then i do indeed see the correct response:
<commit-queue xmlns='http://tail-f.com/ns/rest'> <id>1617288642727</id> <status>timeout</status> </commit-queue>
And there's queue item:
System message at 2021-04-01 14:50:42... Commit performed by admin via http using rest. admin@ncs# *** ALARM connection-failure: Failed to connect to device asr9001b: connection refused: NEDCOM CONNECT: Connection refused (Connection refused) in new state admin@ncs# show devices commit-queue WAITING TRANSIENT IS ID TAG AGE STATUS DEVICES FOR ERRORS COMPLETED ATOMIC NAME REASON NODE ID -------------------------------------------------------------------------------------------------------------------- 1617288642727 - 45 executing [ asr9001b ] - [ asr9001b ] - true admin@ncs#
So looks like it was my setup throwing me off.
Thanks for pointing me in the right direction.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide