How commit-queue really works in NSO?

[Elvin J]

I have one device southbound locked and one active device. One service is managing those two devices.

When I send PATCH request to "/restconf/data/?commit-queue=async" , commits are queued for locked devices, this is fine.

However, commits are not queued for active devices, when I send PATCH request to same service before previous commits get completed for active devices, I get error 

<error-message>Commit failed because commit queue item 1714732173992 has an overlapping service or device modification.</error-message>



Why it does not queue the commits for active devices?  Isnt it whole idea of commit-queue?  

My global settings are 

devices global-settings commit-queue error-option rollback-on-error

[cohult]

Are you looking for the /restconf/data/?commit-queue-atomic=false option?
See the NSO UG and RESTCONF docs.

[Elvin J]

Thanks for the answer, but  no.  Even I make changes on same active device. I get the error above Since previous commit was not completed. 

[cohult]

From the NSO UG:

To guarantee service integrity NSO checks for overlapping service or device modifications against the items in the commit queue and returns an error if such exists.  If a service instance does a shared set on the same data as a service instance in the queue actually changed, the reference count will be increased but no actual change is pushed to the device(s). This will give a false positive that the change is actually deployed in the network. The rollback-on-error and stop-on-error error options will automatically create a queue lock on the involved services and devices to prevent such a case.

The point of commit queue is to allow several transactions to push configuration to devices concurrently. When using rollback-on-error or stop-on-error, overlapping service or device modifications in concurrent transactions result in an error as described by the NSO UG.