My question is specific to subscription functionality. Does premium confD support addition/deletion/modification of subscription at run time without closing and resubscribing modified list of candidate paths.
in confD basic procedure seems to be closing the subscription socket and resubscribing modified list of paths.
it seems a limitation in confD basic.
It works the same, by design, in Basic and Premium. Once you have called cdb_subscribe_done(), notifications may arrive asynchronously on the socket, which would interfere with the replies to any hypothetical unsubscribe/subscribe requests. Basically cdb_subscribe_done() tells ConfD that you are done(!) with the socket, and it is subsequently “owned” by ConfD.
Have you actually considered the consequences of dynamically un-subscribing/re-subscribing? As soon as you unsubscribe, you will (obviously) not get any notifications of changes to the subtree in question, and if you then re-subscribe to the same tree, you have no idea which changes may have occurred, and have to “start over” to figure out the current config, either by “full read” or by cdb_trigger_subscriptions(). This implies a complex and inefficient design.
If you still think this is a good idea, it is perfectly possible to do the “subscription change via new socket and close of the old one” without losing any notifications for subscriptions that you actually want to keep, nor getting duplicate notifications. Simplest case is of course to only have one subscription per socket.
I think addition/modification/deletion is basic requirement in virtualization world.
For example we have 100 of objects and different objects are handled by different VNFCs(Virtual machine).
Now due to load balancing or scale in/scale out these object keep moving across VNFCs or new Object gets added, deleted for new VNFC or deleted VNFC respectively.
list A {
key a;
leaf a {
type u32;
}
}
All objects are element of same list, Now each VNFC can subscribe 1 or more leaf a. But leaf a can not belong to two VNFC. Suppose VNFC 1 came up, then it subscribed a = 1 and a = 2. Now due to load scale in happens and one more VNFC come up and we want to move key a = 2 to VNFC 2 and want to remove key a = 2 from VNFC 1 subscription points.
I hope it clarifies the use case.
OK - so doing one subscription per socket seems to be a good fit for the use case.