Clarification on OOS Node Redeploy: Hi Team,Please help to confirm that the following scenario is correct or not.1. Create a L2VPN Service2. Bring any one of the service node out-of-sync3. Edit the service and commit changes4. The service will be pushed unto "failed" state.<ul><ul>Now click on re-deploy from the provisioning nso action button. Should this bring the service Success or say error that the particular node is outof-sync?</ul></ul>Please help to confirm
If you did not commit any action (sync-from/sync-to) to make the device in-sync, then yes a re-deploy of the service will still be in the "failed" state, assuming the commit has gone through ( usage of commit-queue or non-commit-queue but resource-manager allocation was required by the service )Thanks,RegiThank you.That seems to be a desperate issue. I have filed the Defect - CSCwb54540I'm seeing the service getting success even when I did not commit any action (sync-from/sync-to)I've updated both the CDETs as they seem related:It would be good if we can have a quick webex regarding this issue.Thanks,RegiHad webex session with Kanchan. The reason this issue was occurring is because service did not have ownership of the device configs as the device configs existed before service creation.I had Kanchan do a "re-deploy reconcile" of the service to re-take ownership of the configs. You can also clean up the device manually and do a sync-from as well if you do not want to do a "re-deploy reconcile". After this step, can you re-test this scenario and let me know if you are getting the expected results or not.Yes. I can perform re-deploy reconsile very well. but I would strongly say this is not the test scenario.The expectation is that any service should take the ownership on the very first commit-changes click at the time of service create.I would still test this following steps described as part of defect debug.Thank you very muchThe reason the service does not take ownership is because the configs existed on the device before service creation. That's also why you do not see dry-run output for the devices. This is expected behavior as far as NSO is concerned.NSO has a feature which does reconcile on first commit which is "commit reconcile", but this option doesn't seem to be available on CNC GUI which is why I suggested the "re-deploy reconcile"Thanks,RegiCould you please confirm, re-deploy reconsile of the service which has OOS/Unreachbale node should be successful or throw error?Hi Dinesh,When you edited the config with out-of-sync device, this commit was rejected and service plan reflects failure and that's to be expected but once you do a service re-deploy, in this case, the service rolls back to the previous provisioned state which was successful in this case ( since there are no new commits to be made by the service as previous commit was rejected ), so this is the expectation.Please let me know if you have any questions.Thanks,RegiHi Dinesh,Please let me know by EOD today if you have further issues; otherwise, I will go ahead and close this ticket.Thanks,RegiHi Regi,It is cleared that commit-queue global setting of the NSO cluster has to be set "false" and to sure that the device does not have any existing configuration of the same service.Hence the service owned by the devices will resolve these intermittent issues.You can please close the ticket.Thanks,Dinesh