ConfD User Community

Lock from Netconf client and external DB


#1

Hi,

I have questions regarding 27.2 section - lock().
we work with external DB.
What should we do in order to implement the Netconf operation according RFC 6241?
I have read section 27.2 and I see only explanations regarding trans_lock which is not the same.
I also read that the CDB (which we don’t use) ignores the lock/unlock operations. why? If we also work with DB transactions, can we ignore it too?

Thanks and regards
Inbal


#2

The locks you’re referring to here are the ones that can be taken from NETCONF and other northbound interfaces and are known as Global locks in 27.2. Locks (28.2 in newer versions of ConfD).

Read more in sections 27.2.1. Global locks, 27.2.3. Northbound agents and global locks and 27.2.4. External data providers.


#3

Hi,

what is the callback that confd execute when Netconf or cli is being opoerate?
I guess it is not the transaction lock() which is relates to specific transaction.

thanks
Inbal


#4

The trans_init( ) callback will be invoked when ConfD enters into a transaction as depicted by the ConfD transaction state machine in Chapter 7.5 of the ConfD User Guide. The trans_lock( ) callback gets invoked by ConfD when a transaction is committed or when a transaction is validated through either NETCONF or CLI, and the transaction enters the VALIDATE state.

If you have chosen to implement the optional lock( ) callback which is only interesting if there exists additional locking mechanisms towards the external database - such as an external CLI which can lock the database, or if the external database owns the candidate. The lock( ) callback when implemented will be invoked to get a chance to refuse or accept the lock when a global lock on a datastore is being requested.


#5

Hi,

Sorry, I think something was missing in my question.

I mean to ask, what is the callback tha tconfd execute when cli/netconf operates “configure exclusive”?
If I understand the RFC, when user execute this command the CDB should be locked.
What is the callback that is being issued for this command so external DB will be locked?

thanks
Inbal


#6

If you have implemented the CDB datastore (running and/or candidate) as an external DB, as Wai writes, the optional lock( ) callback will be called if you have registered for it when a northbound interface, e.g. NETCONF, CLI etc, lock that datastore.
As mentioned before, see confd_lib_dp(3) man page confd_register_db_cb() for details.


#7

Hi,

According to RFC 6241, section 7.5, there is a NetConf command “lock”.
From the RFC:
rpc message-id=“101”
xmlns=“urn:ietf:params:xml:ns:netconf:base:1.0”

{lock>
{target>
{running/>
{/target>
{/lock>
{rpc>

What is the callback we should implement in order to support the command in our external DB?

Thanks
Inbal


#8

See my previous response to this same post at Lock from Netconf client and external DB.

NETCONF <lock> will cause the lock( ) callback to be invoked when implemented. You should read about my explanation on whether the implementation of this callback is necessary for your use case.


#9

Hi,

the lock mechanism is not needed in regular configuration transaction.
However, we would like to support the Nectonf lock>.
I observed that once I register to that callback, I receive lock() callback for each transaction. Is there a way to distinguish in the callback why it being called - is it part of the configuration transaction or since lock> was called?

10x


#10

I hesitate to suggest it, given that there has been extensive discussion about both lock() and trans_lock() in this thread - but perhaps you actually registered trans_lock(), and not lock()? trans_lock() is a transaction callback, registered via confd_register_trans_cb(), while lock() is a DB callback (i.e. it doesn’t pertain to a specific transaction), registered via confd_register_db_cb(). (The name of the actual function you register is of course completely irrelevant.)


#11

Thank you very much for your clarification. I was not aware that these are different callbacks, and now this issue is clear.