Operational data not get deleted from cdb when application writing to DB stops


We are using Confd version 7.3. We are writing operational data to confd operational db. On killing the application which is writing operational data to cdb, we expect the data to be deleted/cleaned from the operational cdb itself.

Kindly suggest.


This is because you are using cdb_... functions, they immediately modify the CDB data. You can modify operational CDB by using the MAAPI: start a new session, open a transaction towards OPERATIONAL, write data, apply the transaction and finish it. This is used in the stats-push example in the ConfD release.

Using transactions means that the data do not appear in the CDB until the maapi_apply call so if your application is killed before that, no changes make it to the CDB. As a bonus, OPERATIONAL subscribers (if you have them) require this approach, otherwise subscription notifications are not sent.

Thanks Martin for the quick response.

Actually the query is bit different. Our intention is not only to delay the changes to be applied until maapi_apply() is called(making the transaction atomic).
Our intention is, as the operational data is related to the the application connected, and there could be multiple applications connected at a time.
let’s say one of the application gets disconnected(killed or stopped) to confd server. The data belonging to that application shall get deleted from the confd operational db by itself.

Please guide us, if this is achievable in confd while not modifying the yang model.


I see. But this is not a task for ConfD, or at least, not for ConfD alone. I think you need to have something like a watchdog, or at least a data provider that serves simple data based on what applications are alive. With it, you can either do the manual deletion itself, or just flip a switch that would indicate what application data are supposed to be alive, or something in this vein; nothing really automatic that I am aware of.

Thanks for the response!

Actually the intention behind exploring this behavior was, we are already using another Opensource Netconf client/server module(Sysrepo-Netopeer2) for OAM, and expect to duplicate the same behavior in confd.

Anyways, we will explore if some such functionality we can add to our code/logic.