Backward incompatible NED model changes vs service code changes - NED migration procedure

[rslaski]

Guys,

In case where YANG model changes, so that necessary service template adjustments are necessary, is there any way for the service to use both old and new NED models in the template? For example, old NED uses leaf-list:

        <ip xmlns="http://tail-f.com/ned/arista-dcs">
          <routing>
            <vrf>{$VAR_VRF}</vrf>
          </routing>
        </ip>

while the new requires additional container for the same purpose:

        <ip xmlns="http://tail-f.com/ned/arista-dcs">
          <routing>
            <vrf>
              <vrf-id>{$VAR_VRF}</vrf-id>
            </vrf>
          </routing>
        </ip>

With incorrect model, service package just won't load.

Unfortunetely there's no way (that I am aware of) to use per-version namespace, so we can't have something like:

        <ip xmlns="http://tail-f.com/ned/arista-dcs-5.12">
          <routing>
            <vrf>{$VAR_VRF}</vrf>
          </routing>
        </ip>

        <ip xmlns="http://tail-f.com/ned/arista-dcs-5.16">
          <routing>
            <vrf>
              <vrf-id>{$VAR_VRF}</vrf-id>
            </vrf>
          </routing>
        </ip>

Would you recommend the following NED migration procedure for such cases?

1) Load both NED versions

2) Update service code to align to the new NED model

3) Update service package on NSO, and leave it non-functional after package reload

4) Migrate device NEDs

5) Reload packages to bring back service to life

[vleijon · Accepted solution]

There is a processing statement if-ned-id that can be used for these cases, examples.ncs/getting-started/developing-with-ncs/26-ned-migration is probably a good starting point. (Hopefully I understood your questions correctly).

[rslaski]

Thanks @vleijon for the hint, it works now. The fun fact in this case was the YANG model has changed, however the resulting XML did not, but even then I had to distinguish both versions to avoid package load error

        <interface xmlns="http://tail-f.com/ned/arista-dcs">
          <Vxlan>
            <id>1</id>
            <vxlan>
              <?if-ned-id arista-dcs-cli-5.16:arista-dcs-cli-5.16?>              
                <vrf>
                  <name>{$VAR_VRF}</name>
                  <vni>{$VAR_VNID}</vni>
                </vrf>
              <?elif-ned-id arista-dcs-cli-5.12:arista-dcs-cli-5.12?>              
                <vrf>
                  <name>{$VAR_VRF}</name>
                  <vni>{$VAR_VNID}</vni>
                </vrf>                
              <?end?>
            </vxlan>
          </Vxlan>
        </interface>

Guys, If Cisco can't provide any 'good enouh' NSO documentation, shall we start creating community based one?

[vleijon]

Yes, I have had that case too where a model change results in identical payload in my case but technically incompatible payloads.

As for lacks in documentation that is at least partially my fault. We are trying to put some more effort into this, so let me ask you this: What kind of documentation would be the highest priority for you? What would be the most useful pieces?

For instance, in this particular case if-ned-id is explained in the development guide – but the documentation turns up on page 281 in the pdf (in a table of processing instructions that is well worth reading!). What kind of organization would make this easier to find?