search

CESNET / netopeer2

NETCONF toolset
BSD 3-Clause "New" or "Revised" License
289 stars 185 forks source link

Can netopeer2-server be used against a custom datastore implementation? #1585

Open bala1796 opened 1 month ago

bala1796 commented 1 month ago

I had a look through the documentation and it looks like netopeer2 uses sysrepo as the datastore. Is it possible to use our own datastore and still use netopeer2-server? My research led me to sysrepo's datastore plugin APIs - can they be used to achieve what we want? We do not want to use sysrepo to manage the data but rather want netopeer2-server to interact with our application directly. What is the best way to achieve this?

Thanks.

michalvasko commented 4 weeks ago

Is it possible to use our own datastore and still use netopeer2-server?

Yes.

What is the best way to achieve this?

Definitely using a custom DS plugin. Just note that is not trivial to write it correctly but if you do, it is the best and most efficient.

bala1796 commented 3 weeks ago

Thanks for the confirmation.

Is there any way to completely get around using sysrepo and connect netopeer2-server to our application? (I'm guessing no?)

I apologize if this question sounds trivial, but if we choose to implement this custom DS plugin, we would not want to maintain a "copy" of the database in a sysrepo context. Does this custom DS plugin enable sysrepo to directly map to the configuration database held in our application's memory?

Also, if sysrepo directly has access to the app configuration, does sysrepo handle RPCs (such as edit-config, get-config etc.) and modify the configuration itself or is it possible to delegate the work to our application for every RPC?

michalvasko commented 3 weeks ago

Is there any way to completely get around using sysrepo and connect netopeer2-server to our application?

netopeer2 needs a datastore and a middle layer between NETCONF and actual configuration data so no, this is not possible even in theory.

Does this custom DS plugin enable sysrepo to directly map to the configuration database held in our application's memory?

That is precisely what it enables, if you choose to write your plugin that way. The plugin are just callbacks that are mainly supposed to store and load the data. Where the store/load them from is totally up to you.

is it possible to delegate the work to our application for every RPC?

No, why would you want to do this? Your application (using the plugin API) will only get the processed and broken down changes of an edit-config and similarly processed all the other RPCs.