Basic questions on the API to ConfD

Core Engine and APIs
1

Hello,

Have few basic questions on ConfD deployment and the APIs.

  1. Do you usually have a single ConfD running in the overall system? or multiple of them? I would assume the former since multiple ConfD somehow complicates the design. If I have multiple running instances and I want notification from a specific data provider, I need to know which ConfD instance to request it from. Is my understanding correct?
  2. If I’m implementing a configurable entity, just like the dhcpd_conf example in confd-basic-7.6/examples.confd/intro/1-2-3-start-query-model.
    First - what is this #define dhcpd__ns 1946994318
    What is this ns? namespace?

Second, Is there any way to implement such subscription using a different library? or am I must use libconfd API? I would assume I must use libconfd since it is the glue/shim layer to talk with ConfD.
In the case of this dhcpd_conf example, what is the protocol between the dhcpd_conf executable and ConfD? Is it some kind of a proprietary protocol (CDB related?).

If I want to traverse the received data using something else than the “fmt-like” API, can I use something like YDK?
Or something like a runtime yang parser? Is there a way to deserialize the data reply to something that I can traverse eaasier?
Or am I locked into using this API where I need to pushd/popd and similar? I’d assume I must use this API to traverse the received data tree.

thanks,
Kobi

2

Depends on what you mean by “system”… Typical use case for ConfD is on-device management of the said device. You can integrate remote “device parts” of course, but most of standardized models are one device instance specific either way… When discussing many devices, we are moving one layer higher with some new challenges, and into NSO/NCS orchestrator domain possibly…

Depends on what specifically you mean by notifications (northbound client notificaitons or southbound intergration-related ones (e.g. cdb changes etc.)) and “data provider” again, but generally it is done against specific “device” - IP address + port, so yes, unique ConfD instance.

Right, namespace hash created when compiling YANG module into FXS (resp. when generating integration code headers from FXS), that allows ConfD (or confd-lib user) to uniquely identify YANG module in the integration code…

Do you mean southbound CDB changes subscription (confd-lib), or northbound configuration changes notifications (NETCONF notifications, for full ConfD also JSON-RPC subscriptions)?

Assuming southbound - correct. You can customize some aspects a bit (e.g. adding extra encryption over IPC sockets, etc.), but most of southbound integration code is dependent on confd-lib.

confd-lib covers quite a lot of user-cases, but has quite extensive description and man pages for most of its APIs.

Some protocol description is touched upon e.g. in ConfD user guide chapter “The Protocol and a Library Threads.”

you may need to clarify here which part of the pipeline you mean - integration layer between confd and device, or client/user northbound APIs?

1 Like
3

HI,

yes, you are right. One ConfD instance (often running on the device) is more common scenario. Several devices (ConfDs) are then managed by Network Orchestrator, like NSO. If you have more instances, and want to connect data provider to the specific one, you should use concrete sockets (CONTROL_SOCKET, WORKER_SOCKET), connected to the desired instance.

You are writing about notifications, so I assume you mean rather CDB subscriptions, than data provider.

The #define dhcpd__ns 1946994318 is data model namespace id (number) generated from fxs file (fxs is build from yang). It is used by some ConfD API functions.

Yes, libconfd is layer between ConfD and API. In theory you could implement everything yourself, use own socket communication, but this would be big task. libconfd source code is included with ConfD.

Received data (notifications) must be handled with libconfd API. For subscriptions it is cdb_read_subscription_socket and cdb_diff_iterate.

Detailed info how to read CDB subscriuptions can be found in this video:

1 Like
4

Hello @mnovak - thank you for the video. I’ll definitely take a look at it.

yes, you are right. One ConfD instance (often running on the device) is more common scenario. Several devices (ConfDs) are then managed by Network Orchestrator, like NSO. If you have more instances, and want to connect data provider to the specific one, you should use concrete sockets (CONTROL_SOCKET , WORKER_SOCKET ), connected to the desired instance.

Yes, this is what I was thinking. And yes, my question is all around the CDB subscription aka South bound. The North Bound is straightforward. It’s Netconf protocol coming from management and such.

The #define dhcpd__ns 1946994318 is data model namespace id (number) generated from fxs file (fxs is build from yang). It is used by some ConfD API functions.

Is this something that both ConfD and the subscription endpoint agree upon?

Yes, libconfd is layer between ConfD and API. In theory you could implement everything yourself, use own socket communication, but this would be big task. libconfd source code is included with ConfD.

Understood. This is what I thought.

In other words, if I have a system with multiple processes, all working Southbound/CDB with ConfD, and somehow I’m integrating a new piece of SW from a 3rdparty that is using, say, Netopeer2 from Sysrepo, this piece of Software has a different way to communicate (Southbound) with Netopeer2. I will need to re-write the SB part of this new piece of SW to work with ConfD CDB as the SB APIs are different between different NC Servers Ecosystems.

thanks again!

5

Hi @josephm many thanks to your reply.

So let’s assume I have a machine, x86 or anything similar, running whole network stack. This network stack is combined of 5-6 processes. All processes have configuration requirements. But these processes are all one logical system. I’m specifically working on wireless 5G stack.

Now, there are few ways to deploy ConfD instances.

  1. One per process
  2. One for the entire system.

I would think that the latter is much more simpler. Simpler to deploy, simpler on the North bound interface that need to deal with a single instance, and even on the South Bound interface, if I have multiple ConfD instances and a process need subscription from multiple instances, it’s a complicated way. (say it has subscription for config notifications related to other apps/processes).

My question, what do you see in the industry? what is more common?

When discussing many devices, we are moving one layer higher with some new challenges, and into NSO/NCS orchestrator domain possibly…

Exactly. And the question, why do we need to have multiple ConfD instances?

you may need to clarify here which part of the pipeline you mean - integration layer between confd and device, or client/user northbound APIs?

Southbound. If I want to have a more modern programmatically way to traverse the path as part of handling a subscription response, is there a better way to do it vs cdb API with pushd/popd/cd and similar?
Can I, for example, take the reply which contains the data, deserialize it to some YDK like class, and then have a C++ class with accessors and iterators to traverse the tree? Or this needs to be something I code myself to deal with it?

On the NB, I think it’s clear. The NC payload has XML and this can be deserialized easily. And I believe this is what YDK is doing.
But on the SB, I want something similar, or maybe something like yang-cpp that can handle the YANG data, on the SB subscription end, with more modern programming paradigms.

thanks again!

6

My two cents regarding multiple ConfD instances on one system: it is useful in some testing scenarios, but other that that, I have not seen any deployment using it. In general, you need to solve this trade-off:

  • You want your ConfD-managed system to be small - large number of participating components decreases transaction troughput, and since the ConfD API may be quite chatty, the distance between components should be short.

  • At the same time, you want ACID transactions over your system configurations. This is possible with single ConfD installation (ACID configuration transactions is perhaps the most important feature you get by properly deploying ConfD), but much more difficult with more of them, so by splitting your system into many parts you are subverting the key reason why you may have started to think about deploying ConfD.

The dividing line is a bit blurry with edge cases like multi-blade or multi-chassis systems, but one ConfD installation per process is definitely far too fine-grained.

1 Like
7

The #define dhcpd__ns 1946994318 is namescpace ID. I think it is not needed for subsriber, as you subscribe for data model path. It is needed only in some API functions. It is generated from YANG (FXS), so there is no additional information. I guess numeric IDs are used for optimization in APIs as it is more performant to work
with numbers than with strings.

Ok, I guess you need to invent some common wrapper that can be used for all APIs and systems that you need.

1 Like
8

Ok, I guess you need to invent some common wrapper that can be used for all APIs and systems that you need.

True. And it is kinda strange that there lots of stuff need to be manually coded instead of having a way to take a YANG, generate C++(or different lang) classes, and have the whole CDB handling auto generated.

thanks again!

9
  • At the same time, you want ACID transactions over your system configurations. This is possible with single ConfD installation (ACID configuration transactions is perhaps the most important feature you get by properly deploying ConfD), but much more difficult with more of them, so by splitting your system into many parts you are subverting the key reason why you may have started to think about deploying ConfD.

Can the NB interface run edit-config (for example) on the candidate DBs of the various ConfD instances and then ask to commit it to be the running DB? This might help with ACID though I agree it’s tricky.

10

You may be thinking of the legacy stub-based approach. As quoted from the ConfD Kick Start Guide available for download at https://info.tail-f.com/confd-evaluation-kick-start-guide:

Many management agent frameworks are stub based. This means that a command list or data model is fed to a compiler which then generates stub functions that must be implemented, i.e. “instrumentation”. The instrumentation code must handle all application logic like persistence, error-handling, mapping to the underlying resources, etc. This legacy approach does not handle changes in data model well.

ConfD turns the legacy approach of stub generation upside down. ConfD is a complete agent and uses a subscription-based programming style, based on the YANG data model. Northbound APIs and User Interfaces are automatically runtime rendered. Configuration changes are made persistent in the built-in datastore. As a developer, you can iteratively add subscriptions to the configuration changes and map this to the underlying resources. This has several benefits including iterative/agile development and core features taken care of by the ConfD Core Engine. The developer can focus on the application logic.

1 Like
11

Thanks Wai.
I understand some of the motivation of not going with Stub based approach where the stub is generated.
That said - I have a feeling that one of the 2 approached will be used by the users:

  1. Manually coding all subscription options, iterating over replies with a full knowledge of the schema. When I iterate over a specific reply, I know what I’m looking for, child, siblings etc… But it means a special code is written to parse any reply. Maybe I’m missing here something and there can be a single iterate loop for virtually every single subscription.
  2. People will opt to an XML representation. I just discovered this: How to convert a ConfD tag value array to XML? . So I can generate an XML and pass it to something that can deserialize it or hand it over to something else that understand XML and can extract the values. But it’s slower than having it done directly with the C-API. Slower because it still string generation.
12

This approach is shown with the example under examples.confd/cdb_subscription/iter_c in which the CDB subscriber code has full knowledge of the schema when processing the notification.

The other approach in which the CDB subscriber code isn’t aware of the schema is shown with the example under examples.confd/cdb_subscription/modifications. The cdb_get_modifications( ) API call is being used to retrieve all the changes that caused the subscription notification. In this example, it has demonstrated the generation of the simple body (only) of a NETCONF edit-config request in XML format.

I would agree that the second approach is typically slower.

1 Like