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