Rollback problem of service in NSO when we have multi backpointer

[ysfabnsr]

Hello,

It is known that it is preferrable to not config the same part of a router with multi services in NSO, but in case we are obliged to do it.

Is there any recommended workaround because for example if we have service A configuring as number in the bgp section then we have another service B which change the as number in the bgp. Now we have two backpointers for that config. If we want to remove the configs done by service B, NSO doesn't do that and doesn't return the config as it was previously with Service A.

Is there any workaround that permit to deal with multi services touching the same config of a router?

is it possible to use action point but there won't be any traceability in the database If we use action point instead of servicepoint

[Daniel Kratz]

Hi @ysfabnsr ,

Reading your post I saw you already know what you have to do... For long term, you need to run a services redesign.

One thing you can evaluate as a workaround is run service A re-deploy right after the service B delete operation in your service flow. Depending on your ecosystem, it's easy to implement.

About traceability you mentioned... there is a risk behind it. Since the moment you deploy service B, service A get out-of-sync. If someone else run a service A re-deploy, your service B will get out-of-sync, and your provisioning intent get broken together.

Hope it helps...

[snovello]

The cleanest solution is really to have one service responsible per part of the config. In your case a stacked service design, where a service is responsible for bgp config would do the job. Then the other services would make use of the bgp service, for example by adding a neighbor. Theese services would then not have to know the AS number at all, because that would be part of the BGP service. Simply changing the AS number in the BGP service would then work directly

For the specifc case of BGP config that sits under an AS, there are shortcut solutions. For example you don't include the AS inumber in the service definition. The services read the AS number from the device config or some other DB location you choose, and then use that value to configure under that AS. Whenever you change the AS number in that DB location all the service change their intent so you don't have an issue with one being in sync while another is no longer in sync. In. this case you can just remove and recreate the BGP config under a different AS number and the services will stay in sync. You would do a redeploy reconcile to fix the backpointers.

[ysfabnsr]

so the suggested solution is to have a kind of inventory which is not related to a service and services use this inventory for the configurations in common

[snovello · Accepted solution]

The preferred solution is to have a common service for the common configuration. The templates of other services will contain requests towards that common service.

So I have a common bgp service, key is router name. It has an AS leaf. and under that services it has a list of neighbors AF's whatever you confgure under BGP, . In the template of a l3vpn service I mention the bgp service with router key, and some neigbour that is needed for the l3 vpn. The bgp service takes care of the config of that neigbour. That is the stacked service pattern. A service represents its intent in its template in terms of other lower level services rather than directly specifying configuration.

I can see that might be a big change, so you could just start with some configuration (here just the AS number), outside of the service that is referenced. Note than whenever you do this, and change that external configuration all your referring services are potentially out of sync and need to be redeployed. Using the AS number as read from the configuration (reading it from cdb) is one specific way of implementing that external inventory, but you can also write a yang model for your inventory data, and that tends to be cleaner and works across device types - unlike reading from the config.