Are there any known known limitations to using external db?

CDB and CDB API
1

Hi All,

While going through the user guide, I did not notice any netconf operation (base or optional capability) being mentioned as unsupported because of using external DB instead of the inbuild CDB.

Is the limitations covered elsewhere in the user guide ,any pointers here would help.

~ascesh

2

There are no limitations to any northbound interfaces when using an external database instead of CDB. All requests that come in via a northbound interface are translated using an internal version of the Management Agent API (MAAPI), and so the transaction is also agnostic as to which northbound interface the request came in as well. The ConfD core engine then takes this transaction and will eventually update CDB or communicate with the external data provider as specified in your YANG model.

1 Like
3

Thanks for the clarification greg :),

Am trying to understand how transaction support works in general in confd and with external DB.
i.e how does the southbound external db providing daemon participate in a transaction.

could you point me to any docs,links that explains the same.

~ascesh

4

I managed to locate the section " 7.7. External configuration data with transactions" in the userguide,…
and also the corresponding sample code in simple_trans dir.

for applications which currently don’t have a concept of checkpointing or transactions ,there seems to be a way to accumulate write operations, using the prepare() callback and CONFD_ACCUMULATE in create(),set_elem(),etc…and then to commit() them at once ,

In the sample code , the commit is a simple operation of copying running.prep to running.db ,
BUT in the real world this step might fail in between .

So my specific query is:

Is there any API/ helper function in confd which can compute the undo information (like a C_CREATE with old value for a C_REMOVE ,C_SET_ELEM back to the old value ) and call back the southbound external DB provider to revert back its state , back to when the commit originally started.

I guess with such a feature api, the southbound application does NOT need to learn about transactions at all ,simplifiying its implementation.

i.e every partial commit results as in a series of undo steps like in the cli’s ’ show configuration rollback changes’

OR

Is there a way to access the ‘show configuration rollback changes’ itself prior to commit ,to derive the undo information in the southbound application.

5

Hey All,

Just trying to bump up the thread , any thoughts ?

6

You can get the equivalent of a rollback file for a given configuration before it is committed (or a subtree thereof) in curly bracket format using maapi_roll_config()

See confd_lib_maapi manpages.

Example:

id = maapi_roll_config(maapi_socket, tctx->thandle, "/");

addr.sin_addr.s_addr = inet_addr("127.0.0.1");
addr.sin_family = AF_INET;
addr.sin_port = htons(CONFD_PORT);
streamsock = socket(PF_INET, SOCK_STREAM, 0);
confd_stream_connect(streamsock, (struct sockaddr*)&addr,
                  sizeof (struct sockaddr_in), id,0);
while ((r = read(streamsock, buf, sizeof(buf))) > 0) {
   //do something with the rollback info here
}
close(streamsock);
maapi_roll_config_result(maapi_socket, id);
7

Ok , since the configurations are being done by a external netconf client/cli… (and NOT through maapi)
I guess the right time to call this maapi_roll_config() , is at the start of commit() callback.
Am I right ?

8

It doesn’t matter if the configurations are being done over NETCONF, MAAPI, CLI, … A transaction is a transaction no matter what northbound interface it originates from.

We know nothing, so far, about your external DB, so it is up to you to decide when it is the “right” time to call maapi_roll_config() during the transaction.