Is it possible to load multiple versions of a yang model simultaneously into confd

YANG
1

I wish to support old and new versions of software towards confd’s southbound interface ,
so wondering if anyone has tried this before …
and how would the c-api DP api’s be able to differntiate the calls of say get,get_next of the two releases??

1 Like
2

ConfD will only load the latest version of a YANG model at runtime. ConfD will only communicate with one set of data provider daemons (of the same revision) on the southbound side.

1 Like
3

Thanks …
am guessing it’s not possible to even load a renamed yang file also (like routes_oldrelease.yang) , since when seen from netconf client ,the parameters being modelled will appear as duplicates as the parameters would all be loaded into the same namespace.

am I thinking in the right direction ??

4

Hi ascesh

Correct. You can for example rename the namespace of the old version, and then not export it over the northbound interfaces if you wish.

See confdc man page “–export” flag for more on how to make the namespace visible to “none” except southbound applications.

But why you would like to keep both new version and old version data in the datastore simultaneously? If it is for upgrade reasons, there are other ConfD mechanisms that are likely more suitable.

5

Hey Cohult ,

Yes,it’s for upgrade reasons that we wish to keep the old and new versions of data.

Because in our deployment, confd will be deployed in a centralised configuration management server.
which will need to forward configuration updates to worker nodes (do you have any suggestions here on how to forward the configurations, I am aware of confd as sub-agent concept, is there any other suggestions ).

and it’s possible the all the worker nodes are not upgraded at the same time … i.e few are upgraded to new release first.

so for the intermediate period of time when both versions of software are running in the deployment , we will need to support two sets of yang versions :slight_smile:

1 Like
8

Hi Ascesh,

Your upgrade scenario, running old versions in parallel with new versions, is sort of making your main ConfD into an EMS which is not what ConfD is targeting. You will have to add some functionality yourself as discussed earlier.

As inspiration, here are some examples of a “roll-your-own” distributed ConfD, besides the subagent concept:
https://cisco.box.com/s/9b0qf3xsaerurhg6jxqzsspty6h91cu9
All examples require you to do some work.

EDIT: link to a ConfD demo github example https://github.com/ConfD-Developer/ConfD-Demos/tree/master/confd-sync-py

2 Likes
9

Hi cohult,

Could you give me the permission to see the examples from the link you posted ? I am interested in checking them.

Thank you.

10

reviving this thread.
First, is it possible to get access to the box.com example?

Second, the way I see it, the SB need to be written in a way where it is handling changes in the schema and either ignore, error, etc…

Third, if such distributed env, I’d probably have ConfD attached to a “system” and a system might be one or group of processes that will be deployed and updated together. In a K8s, I’d see it as a pod. so ConfD per pod.
when you upgrade, you upgrade the entire pod which would have a container for the confd and container for other processes. In one specific time, you might have a mixture of ConfD which holds different revisions of the schema and NB would need to be aware of it. Probably by looking at the schema list and content.

does the above make sense?

11

The Box link is from 2016, ConfD Demos that add on to the example set with for example integrations can nowadays be found here: GitHub - ConfD-Developer/ConfD-Demos: Store ConfD Demos here See the EDIT to the original post with an alternative to the Box link.

Makes sense. NSO, for example, would be able to handle the mixture of revisions/schema. The example provided in 2016 would have to be extended with that feature.

1 Like