Problem with a Service that add devices to NSO

[Gastonper]

Hi, I have to following problem.

I made a service that add a device to NSO. The yang model has the needed information to add the device (ip, ned, name, etc.) and other useful information. The idea is to make it easy for OyM.

Right now i have to make a manual sync-from after the device is created.

The problem is that if I change any of the parameters in the service, when I do a comit dry-run, NSO try to eliminate all the config data that the device get from the sync-from.

Any idea why this happend?

Thanks

[yfherzog · Accepted solution]

As your service created the device, if you run 'show run devices device my-device | display xml | display service-meta-data', you'd see that the device's top-level has a refcount of 1 and a backpoint to the service instance.

Once the service is modified/re-deployed/deleted Fastmap is undoing in-memory all those config pieces with backpointers to the service. In case of modify/re-deploy, it then also re-applies the service mapping logic. This recreates the configs which are part of the service mapping logic.

The content of the device config container was not created by the service mapping logic, so it's not recreated, and you end up losing it, because its parent was temporarily deleted in the process.

If you run 'path-to-service my-service-instance re-deploy reconcile { keep-non-service-configs }' (might had a typo here), NSO should adjust the refcounts so that it's increased for all nodes having non-service config under them (e.g. the device top-level).

Run show run with display service meta data again afterwards to see the difference.

This will also mean that removing the service instance will not delete the device.

If that's ok, then instead of running re-deploy reconcile, you can move the device creation from the create() callback to the pre/post modification callbacks, which will exclude the device creation from Fastmap, and should provide more or less the same results as re-deploy reconcile but without backpointers.

[Gastonper]

Thanks! that works.

Not deleting the device when removing the service instance is not a problem for us, so doing a re-deploy reconcile is an easy fix.

[yfherzog]

Great!

If you'd move the same logic you're already using from create() to premod() you won't have to even run re-deploy reconcile :)

[lmanor]

Hello,

I am curious of why you want to onboard the device as part of this service?

Do your devices come and go frequently so that the lifecycle mgmt of the device needs to be automated, i.e. when all config from the device is removed, then the device is removed from management?

Typically, devices are onboarded statically (CDB config only) and then services generally acting upon the device configuration under the config sub-tree.

Just trying to envision the use-case you are attempting to solve.

Thanks

[Gastonper]

My use case is a multi-vendor GPON network, in this case my devices are OLTs. I want to have extra useful information for each device, like vendor, model, software version, etc, and mos important: ONUs conected to this OLT.

So, instead of having just a service with a lists of OLTs and this info, the service also add the OLT as device in NSO.

The extra info are populated manualy when the OLT are created in NSO. The ONUs are added automatically.