Detecting pre-existing service configuration on devices

[previousqna]

Hello all,

Our customer would like to detect situations where configuration exists on a device, that would in normal NSO operation just be considered a no-op. For the customer, this means that someone manually placed configuration that should be exclusively created/managed by NSO. Complicated by the fact that sometimes, this is shared configuration that *should* be there, thanks to another instance of the same service.

We considered a number of approaches, but couldn’t easily find a straightforward one.

Our preferred approach is careful use of stacked services and the “create” tag, so if the (extremely careful, due to leaf-lists and containers without presence…). We’re proceeding with this approach, as it seems the cleanest.

Unfortunately, another approach is being championed by the customer, as they view it as “generic”. I’ve outlined it below. I’d like feedback from the Engineering team on this approach with respect to:

• Feasibility – we think it’s possible, and are doing more work, but you might have a better idea?
• Practicality – have I missed anything from the below?
• Sense – just how crazy do you think this is?

  The approach: High level:

• Call a wrapper action that:
  • Creates the service, with normal merge templates, with “commit no-networking”
  • Check the resulting CDB for clashes (see below)
  • If the result is clear
    • Redeploy the service
  • Else
    • Delete the service
    • Return the details of the clashes.

The detailed part is the check:

For each entry in /services/service/my-service/{key}/device-modifications

If the entry is a remove

Continue;

Else if the entry is an add

Continue;

Else //the entry was pre-existing

Read that entry’s back-references

If there are no back-references

Log warning – we should never get here.

If there is one back-reference

// this entry pre-existed

Add entry to clashes list

Else two or more back-references

//must be shared config

Continue;

Thanks,

[previousqna]

Hello again,

We need to have a discussion about this approach with our customer on Wednesday this week.

Any feedback, primarily from the Engineering team, would be much appreciated.

[previousqna]

Hi,

For configuration that “should be there” for all service instances, one typical method is to check for the configuration and if it doesn’t exist add it in the preMod callback so its not deleted by the service instance.

[previousqna · Accepted solution]

In NSO version 4.2 and newer, shared configuration is allowed in reconciliation logic and was used to great effect in a customer involvement I worked on last year.

The reconciliation logic employed (used also in service creation) works like this: Service creation looks for pre-existing configuration in CDB, reconciles/uses the configuration parts required if existing (leafs are in fact set from the service code) and thereby adding these configuration parts to the current service instance.

In our use cases, two or more service instances share a common BDI / Vlan Interface with L3 configuration (ASR901/903).

For your case, same kind of logic can be used, but you can also do a maapi call to push a service instance “re-deploy reconcile discard non-service-configuration” afterwards, resetting the ref-count pointers of the configuration part which was reconciled, giving ownership of the configuration to the service instance(s).

Sorry for the late response, it seems I haven’t been paying enough attention to this mailer, found this while looking for other answers.

I will be available to demo this next week if you want to see it in action.