In the situation of configuration data, I was wondering why a callpoint cannot be refined with a datastore. Indeed, one can define a callpoint for configuration data, but there is no way to specify if we want it for the running datastore or the candidate datastore. Why such a limitation?
I have read that if confd owns the candidate (configured in confd.conf) then no transaction will be ever created toward the candidate. Does it mean the behavior between the running datastore and the candidate datastore is not symmetric? More specifically, if a dataprovider callpoint is used (registered to) in a daemon for configuration data (i.e CDB is not used for the configuration data of this node and its sub-children in the data model) then for the running datastore the data callback functions (set_elem, get_elem,…) and the transaction callbacks will be called (trans_lock, prepare, …) if registered but not for the candidate datastore ?
Regarding set and transaction hooks I read that in case candidate datastore is used then set hooks are called as soon as a write is performed (a write in the meaning of a write with maapi on a transaction opened on the candidate datastore) and transaction hooks are called when the candidate datastore is committed to the running datastore. Is-that correct?
I am not sure I understand the part when you talk about ‘refine’. Keep in mind that ‘refine’ is used to “refine” nodes defined in a grouping.
There are specific things you can do with ‘refine’: https://tools.ietf.org/html/rfc7950#section-7.13.2
Regarding Running and Candidate stores, you can pick and choose who should handle the data, I.e. CDB or “external”, and this can be done for both running and candidate.
If ConfD owns the candidate, you can still start transactions towards the candidate if you want. Where did you read that no transaction will ever be created towards the candidate? Not sure this is what you are looking for. A transaction can span across both datastores. For example, in one single transaction, you can target the candidate with your edits then commit the candidate to running, all in one single transaction. You can also have transactions towards running only.
There are 5 callbacks that you need to implement if you choose to have an external candidate. It’s not recommended as an external candidate needs to map precisely to a NETCONF candidate, which ConfD does perfectly, in addition to it not being a common use case plus performance.
It is also recommended to keep running in CDB if you don’t want to be burdened with writing extra code to handle transaction related callbacks and if performance is of concern.
You are right about Set and Transaction hooks. Even if the candidate datastore is not enabled, this behavior still applies. The transaction hooks are called when you commit and before the validation phase so that the whole data is validated before writing the Running.
Thank you for your answer. I see that I was not enough accurate with my original post.
What I mean by refining a callpoint (in the Yang) is to be able to select the datastore (running and/or candidate) that a callpoint will be used for.
I read in the chapter 7.9 of confd_user_guide 6.4.3 page 118 third paragraphs: “If ConfD owns the candidate, no transactions will ever be created towards the candidate.”. But that sentence is referring to the dataprovider interface. Of course from the management agent API you can start a transaction to the candidate datastore regardless of where the datastore is actually handled. And the confd engine will, I assume, go through the states of the transactional state machines to handle request from the agent. I also know about the db_cbs callbacks but for the sake of simplicity I just would like to focus first on the trans_cb and data_cbs .
Let’s say we have a callpoint “tailf:callpoint mycp;” in a container where there are config data. Let’s say that I want to provide those data for the candidate data store (and only for this container and its sub-children, so all the tree under that callpoint) in one of my dataprovider daemon but I don’t want to do it for the running datastore. So when I start a transaction toward the candidate datastore with maapi, I would like to have the trans_cb and the data_cb called for this callpoint. How can I do this? At the present time, there is no way to restrict the callpoint to a datastore, there is not way to register callbacks function for a specific datastore (on the dataprovider side then).