adding changable default list items at service creation?

[theandre]

Hi Folks,

Inside my NSO service YANG model, there is a list where I would like to have predefined elements injected during the service creation. These elements should be part of the configuration and changeable with frther commits. I tried to apply an XML template inside the service code to the service itself which give me almost what I was looking for. The only issue was that when I tried to modify the list and commit, it always got overwritten by the default elements. My assumption was that by default NSO will merge these configs, and my changes will remain there, but the changes got lost. Is this possible somehow?

NSO 5.7

Thank you in advance for any recommendation.

[emholmst]

everything depends on how you want the NB client to enter the parameters in your service, i.e. one could change the service YANG module to the following:

    choice interface {
      case automatic {
        leaf default {
          type boolean;
          default true;
        }
      } 
      case manual {
        list interface {
          key "name";
          leaf name { ... }
        }
      }
    }

and check in the template for existence of the default leaf or iterate over interface list. however. I would rather suggest to be explicit, remove the automatic part of the service and only configure what the user instructs to. maybe it is more obvious if you share exactly what kind of device config you want to configure by default.

[theandre]

Thanks a lot for your response, let me try to provide an example:

YANG:

list tenant {
  container policy {
    list packages {
      key name;
      leaf name {
        type string {
          length 1..63;
        }
      }
      list rule {
        key id;
        leaf id {
          type uint16;
        }
        leaf comment {
          type string;
      
        }
      }
    }
  }
}

Python:

template = ncs.template.Template(service)
template_vars = ncs.template.Variables()
template.apply("tenant-cfs-default", template_vars)

tenant-cfs-default.xml:

<config xmlns="http://tail-f.com/ns/config/1.0">
 <tenant xmlns="http://ngena.com/yang/cfs/tenant-cfs">
  <name>{name}</name>
  <policy>
   <packages>
    <name>package1</name>
    <rule>
     <id>1</id>
     <comment>comment1</comment>
    </rule>
    <rule>
     <id>2</id>
     <comment>comment2</comment>
    </rule>
   </packages>
  </policy>
 </tenant>
</config>

CLI output:

[edit]
admin@nso% show tenant tenant2 policy packages package1 | display set
set tenant tenant2 policy packages package1 rule 1 comment comment1
set tenant tenant2 policy packages package1 rule 2 comment comment2

[edit]
admin@nso% set tenant tenant2 policy packages package1 rule 3 comment comment3

[edit]
admin@nso% show tenant tenant2 policy packages package1 | display set
set tenant tenant2 policy packages package1 rule 1 comment comment1
set tenant tenant2 policy packages package1 rule 2 comment comment2
set tenant tenant2 policy packages package1 rule 3 comment comment3

[edit]
admin@nso% commit 
Commit complete.


[edit]
admin@nso% show tenant tenant2 policy packages package1 | display set
set tenant tenant2 policy packages package1 rule 1 comment comment1
set tenant tenant2 policy packages package1 rule 2 comment comment2

So I would expect to have 3 rules under package1:

- 2 from the XML as default list elements

- 1 added from NB in addition

But it seems that the 2 from the XML overwrites the 1 that was added from NB everytime.

[emholmst]

Hi,

Thanks for your quick response. In the above example I think it is a problem the service attempts to modify itself, a service should always modify something else, it can be device configuration or a different service.

A service creating policy rules is of course a valid use case.

Each service should have one YANG module for input and one YANG module for output.

See the example $NCS_DIR/examples.ncs/getting-started/developing-with-ncs/4-rfs-service/ the user configures a syslog server address in the syslog service, and the service updates the addresses on device ex0-ex2.

in that example packages/syslog/src/yang/syslog-service.yang is used for input and packages/router/src/yang/router.yang (with the submodule router-syslog.yang) for the output.

/emil

[theandre]

Thanks a lot for the explanations above, I just feel there got to be an easy way to solve this. I was able to work around it by applying the template for the default list elements from a post action. The post action result is monitored as precondition in the next nano state, so without it the service will not go further. Also the post-action will only run once, and I was able to modify the service config without noticable issues so far.

I would be more happy with a simplier solution but at least it seems to work.

[snovello · Accepted solution]

Hi,

From your example I see 2 separate issues.

The first issue is your actual problem, i.e. how fastmap works. It is doing a delete/create within a transaction. When you first create the service the template creates the package1 list element, so when you modify the service the delete phase deletes that list element and consequently any of your user's rules, then the create phase recreates the default rules.

So definitely the solution has to be to take the creation of that container outside of the control of fastmap. You implemented a post action which works, but were asking about an alternative that is simpler. Using the pre_modification callback you could have the changes implemented within the same transaction, so possibly no need for a nano-service. In that callback you can query the type of service operation, create/modify/delete, so for example you can apply your template only on create, which would ensure the default rules are created when a tenant is created but would allow them to be removed by the user. Or if you apply on create or modify then on every change to the tenant the default rules are recreated.

The second issue is that you have a service modifying itself. What is meant here is that we have a service whose create template makes changes to parts of the model that are within the service tree configuration portion. Create must be idempotent, so if I run it multiple time with the same inputs it must yield the same results. But the inputs are the service tree, and if create changes the service tree, successive calls may produce different results. In your case, since the solution to the first issue was to take the template out of create/fastmap this second issue just went away.

I am guessing that these default rules are helping a user who is creating tenants directly from NSO CLI or GUI. If there is a system   calling the NSO API, I would recommend taking away the default rules logic from NSO and just letting the calling system create them when it creates the tenant. It is a lot easier to understand and document an API if whatever is created/modified is done verbatim exactly as specified rather than modifications happening in the background. That is the idea of the intent model, your API expresses an intent that is only ever modified by an external system, and the intent is implemented by making changes elsewhere in other parts of the system. Breaking that  intent model is sometimes useful in user interfaces, where you want the system to make simple changes that the user will become aware of like your default rules, but in APIs it is usually better to stay strictly with an intent model.

[theandre]

Hi,

Thank you very much, this was very helpful and it makes perfect sense. I might give it a try using the pre_modification function as it will be simpler. The nano service was given already as the requirement for adding the default list elements inside NSO as well, but completely agree with you that it should come from northbound normally.

Thank you again!