Commit-confirmed with external DB

NETCONF
1

Hi,

I am using Confd with external DB instead of the CDB.
Does confd support in this case commit-confirmed ?
I suspect not because with external DB the confd doesn’t save any DB so how it can know what need to be rollback.

Thanks,

2

Your suspicion is off.

Have you taken a look at the examples.confd/misc/extern_candidate example that implements an external database example with:confirmed-commit support?

Perhaps you want to keep the candidate in CDB and implement the only the below candidate callbacks related to confirmed commit?
See confd_lib_dp(3) - candidate_commit(), candidate_confirming_commit(), add_checkpoint_running(), del_checkpoint_running(), activate_checkpoint_running().

See also ConfD 6.4 UG Chapter 7.9. Supporting candidate commit

3

Actually if ConfD owns the candidate, only the three checkpoint callbacks need to be implemented by the external data provider.

4

Hi,

I looked at the user guide and the example.
My question is if “candidate” will be stored in Confd, what is the role of the candidate in that case?
As I understand, the 3 callbacks should save the DB before the change and load it again in case that the commit will be canceled or delete the saved DB on other case.
So why Confd manage the “candidate” what it do with it?

Thanks,

5

Hi,

To focus more on this issue I will ask another question.
In my application I have already DB therefore it was obvious that we choose to work with external DB (for running) to avoid the need to do sync all the time between the application DB & CDB.
But what about the candidate DB? In my application I have candidate DB as well but I don’t see any problem to have in addition to that candidate DB in Confd.

Can you please explain what should be my advantages\disadvantages when I decide to work with candidate DB in confd?
From my point of view it looks like it is much easier to have candidate DB in confd. Is there something that I miss?

Thanks,

6

Hi,

I will much appreciate if you can answer my question.

Thanks,

7

Frankly, I have a hard time understanding what your question actually is - I’ll jump on the last part of your text that has a question mark:

Regarding this particular statement, I don’t think that there is anything you miss - it is indeed much easier to have the candidate DB in ConfD. And I think the documentation and the examples that you have been pointed to say so, which makes me wonder if this really is your question, and if so why…

8

Hi,

My question is what are the advantages of “candidate” datastore in Confd when implementing the “commit-confirmed” command?
Using the 3 callbacks I just save the current DB aside in file, commit the “commit-confirmed” configuration and if needed I can reload again the saved DB file or delete it.

What is the role of “candidate” here?

Thanks,

9

The candidate data store is a prerequisite for implementing confirmed commit - please see the specification in RFC 6241, in particular Section 8.4.2. I.e. it is not an “advantage”, confirmed commit is defined in terms of specific operations on candidate and running.[quote=“evyatar, post:8, topic:1384”]
Using the 3 callbacks I just save the current DB aside in file, commit the “commit-confirmed” configuration and if needed I can reload again the saved DB file or delete it.
[/quote]
That’s all that an external data provider for ConfD needs to implement in order to do its part of confirmed commit when ConfD owns the candidate. It is far from an implementation of confirmed commit.[quote=“evyatar, post:8, topic:1384”]
What is the role of “candidate” here?
[/quote]
See above.