cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
63
Views
0
Helpful
3
Replies
khgrant
Cisco Employee

Detecting pre-existing service configuration on devices

 

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,

 

Mark

 

1 ACCEPTED SOLUTION

Accepted Solutions
khgrant
Cisco Employee

 

Hi Mark, Dan,

 

 

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.

 

 

Kind Regards,

 

Mikael

 

View solution in original post

3 REPLIES 3
khgrant
Cisco Employee

 

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.

 

 

Thanks,

 

Mark

 

khgrant
Cisco Employee

 

Hi Mark,

 

 

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.

 

 

-Dan

 

khgrant
Cisco Employee

 

Hi Mark, Dan,

 

 

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.

 

 

Kind Regards,

 

Mikael

 

View solution in original post

Content for Community-Ad