1. Topics
  2. Netconf configuration storage

Netconf configuration storage #opendaylight

makuz.dg@...
 

Hi All,

I'm trying to build a device configuration management application using OpenDaylight and lighty.io.
When I'm adding Netconf connector to the network topology I'm able (after device is succesfully connected) to read and modify device's configuration through the data broker taken from the mount point.
From what I've learned (and please correct me if I'm wrong) mount point's data broker delegate all Netconf operations directly to the device so device configuration is kept only inside the device itself - in particular configuration is not available if the device is not connected.

There is a need to store configurations from multiple devices in distributed store for high availability.
My question is:
Is there a way to keep devices' configurations inside controller's MD-SAL storage?

I would like to store, read and modify device configuration even if the device itself is not connected and then e.g. synchronize it later.

Thanks,
Maciej Kuzdzal
Robert Varga
 

On 10/11/2021 21:52, makuz.dg@... wrote:
Hi All,
Hello Maciej,

I'm trying to build a device configuration management application using OpenDaylight and lighty.io.
When I'm adding Netconf connector to the network topology I'm able (after device is succesfully connected) to read and modify device's configuration through the data broker taken from the mount point.
From what I've learned (and please correct me if I'm wrong) mount point's data broker delegate all Netconf operations directly to the device so device configuration is kept only inside the device itself - in particular configuration is not available if the device is not connected.
Yes, netconf mountpoints are completely stateless.

There is a need to store configurations from multiple devices in distributed store for high availability.
My question is:
Is there a way to keep devices' configurations inside controller's MD-SAL storage?
Not out of the box, no.

I would like to store, read and modify device configuration even if the device itself is not connected and then e.g. synchronize it later.
All the building blocks are present, AFAICT, it is just a matter of putting some engineering into getting it off the ground.

Note though, what you are looking for is essentially a cache -- and you get into https://martinfowler.com/bliki/TwoHardThings.html area -- hence there are number of questions, all starting with "what should happen if":

- what should happen if the datastore accepts something the device does not?
- what should happen if both the cached view and the device's configuration changes?
- what should happen if the device changes while it's not connected? (think firmware upgrades)

And then it's just a matter of getting to code written and contributed :)

Regards,
Robert

?
OpenPGP_signature

makuz.dg@...
 

Hello Robert,
 
Thank you very much for your reply.
 
Yes, netconf mountpoints are completely stateless.
Sure, that's what I thought.
 
Note though, what you are looking for is essentially a cache -- and you get into https://martinfowler.com/bliki/TwoHardThings.html area -- hence there are number of questions, all starting with "what should happen if":
 
- what should happen if the datastore accepts something the device does not?
- what should happen if both the cached view and the device's configuration changes?
- what should happen if the device changes while it's not connected? (think firmware upgrades)
 
And then it's just a matter of getting to code written and contributed :)
Yes exactly, you are completely right :)
 
All the building blocks are present, AFAICT, it is just a matter of putting some engineering into getting it off the ground.
Regarding keeping configuration in MD-SAL I considered creating a distributed store (DOMStore) for each device similarly to how it's done in LightyControllerImpl, but since normally it's done only twice for controller's configuration and operational storages I'm not sure if creating more of them is supported especially in a distributed environment. My concerns arise when I've noticed that while building DatastoreContext, setting logicalStoreType automatically sets the dataStoreName as well.

I was also thinking about storing multiple configurations in a single distributed DOMStore instance (e.g. subtrees with own schemes) but I'm not sure if this is supported.
 
If you can point me to the right direction or just turn back from the wrong path it would be great.
 
Regards,
Maciej
1 - 3 of 3