Push configs based on different revisions and nacm rules

[pralala]

Hi all,

Is there a way to support skipping certain configs to a set of devices where nacm rules dont permit?
I have few devices running version 1 which doesnt allow certain configs because of nacm rules.
i have few device running advanced version 2 which allows certain configs in nacm rules.
If i push the configs to version 1 i will get access-denied.


Is there a way in our nso templates, we could filter out certain configs to be pushed to a certain set of devices and skip pushing to another set of devices similar to revision management is done in yang models?

[Jan Lindblad]

NSO has no mechanism that will analyze the payload it is pushing with respect to NACM rules on the devices. It will simply push and get hit by access-denied in case the payload exceeds what the device permits.

Your service package could of course work this into its behavior. Either by using when= statements in the template that trigger on something that signals whether this would be a v1 or v2 case. Or you could implement this logic in python/java in your service.

[apraveen@cisco.com]

Hi Jan,

Could you give some examples of how we can incorporate this version check in the code? We have a service pack which does mapping in both Java and service templates. Examples of how to check versions (module revisions perhaps?) in Java and in the template using when conditions will help.

thanks

Praveen

[Jan Lindblad]

If you could explain what v1 and v2 actually means in your context, I'll might be able to help. Are those different hardware or firmware versions? Are they different routing configurations, or just different NACM configurations? As an operator, how would I know which device use one version or another? Is there a show command to use? Or is this information stored somewhere?