Reading callpoint data with maapi api's

Examples Set
1

In example 5-c_stats we have callpoint on config false (Operational data) container.

For a user application to read such data why we need maapi operations… For user application there is no way to find out if the node is callpoint or regular data store.

Is there any drawbacks or precautions that user application should take care of… when reading such data providers…

2

It really depends on what you mean by user application. In my understanding, “user” is a northbound client of ConfD - so, some actor that wants to read/modify configuration in ConfD., for example:

  • human using CLI
  • script running NETCONF request using CURL,
  • C application using MAAPI to read/modify configuration or state data.

Example 5-c_stats is NOT and example of one of these.

It shows how to implement C application that acts as “data provider”.
This is needed for operational data (config false) callpoints defined in YANG models.

Example use-case:

  • user (CLI/NETCONF/…) requests data in ConfD under path: /arpentries
  • ConfD sees there is a callpoint in the specific container, which means that data for this is NOT stored directly in CDB, and ConfD has to invoke data provider to get actual data from “somewhere”
  • ConfD checks whether it has some registered data provider for this callpoint and then resends data it received from data provider back to original request - user.

–

In example 5-c_stats we have callpoint on config false (Operational data) container.

yes, this is to let ConfD know, that whenever nortbound API / user requests this data (CLI, netconf, etc.), it is not stored in CDB, but ConfD has to ask some callpoint implementeation / data provider for this data before responding them to original user request;

For a user application to read such data why we need maapi operations…

MAAPI is only one way to get YANG data (be it config or operational) from ConfD.
“User application (see my “user” definition in the beginning of my response)” can use (except for MAAPI via confd-lib) e.g. NETCONF (should you have/use some library for that), CLI, REST. JSON-RPC, all depends on your specific requirements and use case.

For user application there is no way to find out if the node is callpoint or regular data store.

You are correct (well, technically, almost - see a bit further).

There is no difference, from user (northbound application) point of view, in using these APIs on parts of the YANG model that are (are not) defined with callpoints - user is shielded from any such knowledge.

(well, of course with exception of e.g. getting an error response when there is problem in backend deployment, and there is no registered data provider for YANG parts with defined callpoint)

So, northbound user requests/API does not (need to) know whether data is under callpoint or not - it just asks ConfD to provide data - and ConfD then either responds with data directly from CDB, or invokes registered (if any) callpoints.

BUT! of course, if you do really want to know whether some part of YANG structure is or is not managed by callpoint - it is possible to get this information in your applications. You can use YANG schema information that includes this info.

e.g . in confd-lib in C, i think you can use flags from confd_cs_node_info of specific YANG node to chekc whther specific keypah is/not stored in CDB or managed by callpoint.

hope i didnt mix in totally unrelated items, i just wanted to clarify items depending on what you mean by user app.