cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
625
Views
5
Helpful
3
Replies

Before Services Deployment validate against custom fields

Hi all,

My customer has a requirement to tag the services that NSO deploys as Critical or BAU, i wish to create a leaf in the yang model of every services we deploy and that leaf is either Critical or BAU. I then need to add preferably in python some validation that checks  that a new services that NSO is deploying does not impact existing Critical services

 

does any one have an example of similar, or can point me the right directions

 

Thanks

Regards

Yale

3 Replies 3

Jan Lindblad
Cisco Employee
Cisco Employee

Adding a criticality leaf to your YANG will be easy enough. Just add it. Possibly with a BAU default value.

 

leaf criticality {

  type enumeration {

    enum bau;

    enum critical;

  }

  default bau;

}

 

Then, when it comes to the python validation you want to run for critical services, things are murkier. What do you have in mind there?

Hi Jan,

 

the logic needs to be something like

 

does the Services that we are trying deploy share/overwrite config of an existing services.

then depending weather the effected/overlapping services is Critical or BAU can we continue with the deployment

 

Eg a service that is BAU can not update or overwrite any config that belongs to a Critical services 

 

Thanks

Regards

Yale

Hi,

 

When multiple services can potentially modify the same nodes in the device model in conflicting ways (e.g. configure description on one interface with two different values), it means that potentially at least one of those services will be out-of-sync at any given moment. In turn, this means that redeploying/modifying/deleting any of them can lead to some unexpected results.

 

Even if you protect yourself through some sort of mechanism that stops BAU from breaking critical, what happens when critical overwrites BAU configs (makes BAU out of sync), and then you need to modify BAU for unrelated reasons?

BAU will try to restore the configs overwritten by the critical service - does execution fails now, even though change is unrelated?

 

All in all, there are some considerations to take into account here.

 

I think that a different approach will be to stack another service on top that conflicting resource:

 

You have this low-level service that will manage the conflicting resource.

It will have a list of the inputs that will be populated by the high-level services (BAU, critical), with the type of service associated to each list entry.

Then, the mapping logic of this low-level service will decide according to all high-level services which provided inputs to this service, what the configs should look like.

 

If we take the interface description a simple example, then the low-level service model will look something like this:

 

list desc-service {
  key "device interface";
  leaf device { ... }
  leaf interface { ... }

  list description {
    key service-path;
    leaf service-path { ... }
    leaf description { ... }
    leaf service-type {
    type enumeration {
        enum bau;
        enum critical;
    }
}

The mapping logic of the above service will consider all entries on list description (taking into account the content and the type of service to request this content), and will construct the final description accordingly, each time the list changes (each time consuming service is added/removed/modified).

 

The mapping logic of both BAU and critical services, will add entries to this service, rather than directly populating the device model.

 

This way, you have a single owner to the shared configs, nothing gets out of sync, and you can apply any sort of logic in order to decide what should be configured or not.

 

Yftach

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the NSO Developer community: