Multi-tenancy in confd

Core Engine and APIs
1

Is it possible to store the data of multiple devices in one single instance of confd.
We are planning to have a central confd server for CM purpose. A central confd server to store the configuration data of 100s of devices.
Is this multi tenancy support available in confd.

Case 1: All the devices share the same YANG model
Case 2: Subset of devices share same YANG model, and another subset share another YANG model.

Though the devices share the same yang model, the values of CM parameters will be different for different devices.

How can we differentiate the device when this is the setup in a netconf RPC request.
For a database update callback, how the callback notifies the device for which the update is done.

2

Hi Sabraham,

Multi-tenancy is not a feature in ConfD but …

To answer your question: Is it possible to store the data of multiple devices in one single instance of confd?

Yes if your model covers a list of devices. Example:

list devices {
leaf id …
container configuration { …}
}

These will be stored in CDB and your applications running southbound of ConfD have to subscribe to the changes in CDB then marshal the data to the device that is identified by id (just an example) => This means the EMS functionality has to be implemented southbound of ConfD. In which case, ConfD will only be playing the role of storing the data, based on the YANG model, in CDB and, providing your central server with a NETCONF interface towards the northbound managers.

ConfD is not designed to cover EMS functionality: It cannot communicate directly to other remote devices except in some cases, it cannot “discover” new devices, etc…

But, ConfD can be used in an HA mode in which a Master ConfD can communicate to other standby ConfDs.

You can also have CDB subscribers or Data Providers run remotely. This is an architecture that is valid and is used in the field.

For case 1: ConfD running in the central server will have to talk to another application running on the same server or remote, which will in turn manage the Network of devices you have (It should be able to discover new devices, to send the configuration that is appropriate for each device when there is a configuration change, it should be able to run as an EMS southbound of ConfD).

For case 2: Same things apply as in Case 1 with a complexity here for the YANG model that you expose in the central ConfD. You can model 2 sets of data, for each kind of device then follow the same workflow, where a subscriber has to be intelligent enough to know which condifugration applies to which device and communicate that to the remote device using your protocol of choice.

Questions to answer before designing a solution:

Are you managing your own devices or any other thirdparty device?
Do remote devices also carry ConfD?
Can the remote devices be configured outside of the central management?
What interfaces are exposed on those devices?

If there is no requirement to be able to manage remote devices outside of the central management then you might consider running ConfD clients in the remote devices. In this case, they can get notified directly by ConfD when there is a configuration change. The only problem to figure out here is the modeling and how the data tree should look like. What configuration different devices can access in terms of configuration, etc…

-Nabil

3

Hi Nabil, Thanks for the response.
One more doubt:

Regarding the upgrade.
lets say, I have a model like:
list devices {
leaf id …
container configuration { …}
}

In this model, all my devices are having the same yang model and are working fine.
Now I want to upgrade one of the devices from the devices list.
As part of upgrade a new yang model is coming in (lets say some additional parameters are added / modified)
Now when I apply the new yang model in confd, will the new yang model be applicable to all the devices in the list?

  • Santhi
4

The scenario you describe is calling for an EMS functionality which ConfD isn’t built for. It will be easier for you to use a real EMS system in this case.

With ConfD, you can still do things around this by adding more intelligence at the southbound side of ConfD (Your client applications).

Example:

list devices {
leaf id …
container configuration {
choice device {
case device1 {
uses device1grouping;
}
case device2 {
uses device1grouping;
}
}

This means that for every new device needing a different model, than the model already at the central management, you would need to upgrade central management YANG and also the client applications processing the new configuration.

It is a complicated approach and prone to errors.

Ideally, you put ConfD on the remote devices and an EMS/NMS system at the central management level.