Using NSO Commit Queues via RESTCONF

[beasleyjon]

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

[perander]

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.

[beasleyjon]

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.

[perander]

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.

[beasleyjon · Accepted solution]

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.