Actionpoint Registration

I have the following actionpoint registered in my .ann file

tailf:annotate "/ni:network-instances/ni:network-instance/ni:loopback" {
        tailf:actionpoint loopback-point;

Main .yang file

 list network-instance {
     key "name";
       "List of network-instances.";
    action loopback {
            description "Loopback";
          leaf name {
              type string;

    }//action loopback

Integrating action support for loopback-poin

        //register the stream for actions to confd 
        struct confd_action_cbs ActionCallBack;
        memset(&ActionCallBack, 0, sizeof(ActionCallBack));
        strcpy(ActionCallBack.actionpoint, "loopback-point");
        ActionCallBack.init = ConfDAdaptorManager::init_action;
        ActionCallBack.abort = NULL;
        ActionCallBack.action = ConfDAdaptorManager::do_action;
        ActionCallBack.command = NULL;
        ActionCallBack.completion = NULL;
        ActionCallBack.cb_opaque = NULL;

        if (confd_register_action_cbs(m_ConfigDeamonContext, &ActionCallBack) != CONFD_OK)
            LERROR(netConfTraceP, <<"ConfDAdaptorManager::Init confd_register_action_cbs FAILED " );
            DEBUG(netConfTraceP, <<"ConfDAdaptorManager::Init confd_register_action_cbs was done " );


The` confd_register_action_cbs gets successfully executed

In confd_devel log I get this:

13-Jun-2019::15:01:40.387 localhost confd[846]: devel-c Daemon ‘ConfdAdaptor’ registered for non-existing actionpoint ‘loopback-point’

Why is this error being seen?

Thanks in advance.

Can someone please answer the above question?

Have you tried
strcpy(ActionCallBack.actionpoint, “loopback”);

It does not work. I get the following in confd_devel.log

14-Jun-2019::16:17:31.009 localhost confd[843]: devel-c Daemon ‘ConfdAdaptor’ registered for non-existing actionpoint loopback`

Please help fix this problem.
Thanks in advance.

Disregarding the errors in your YANG snippets (e.g. annotate instead of tailf:annotate), which I assume are due to writing “from memory” instead of just cut&paste’ing from your actual modules (I don’t see why people do that, but you’re certainly not the only one:-), the most likely cause of your problem is that you haven’t actually used your annotation module when compiling the main module.

A simple way to check this, that doesn’t require starting up ConfD or your application, is to create a .h file from the .fxs (perhaps you do that anyway) - it should include #defines for all actionpoints, callpoints, etc. Demo:

$ confdc -c -a ni-ann.yang ni.yang
$ confdc --emit-h ni.h ni.fxs
$ grep point ni.h
#define ni__actionpointid_loopback_point "loopback-point"

Do you have such a #define in your .h file? By the way, it is a good idea to actually use the defined symbol instead of the string in your code - that way you avoid spelling errors, since they will be caught by your (C) compiler. But using the string should also work fine.

Edit: Sorry, I see that you actually had tailf:annotate, it was just that scrolling the snippet sideways in my browser caused exactly the tailf: part to “disappear”…


After jaka’s suggestion to try

strcpy(ActionCallBack.actionpoint, “loopback”);

I removed the ‘-’ from loopback-point to be on the safe side and avoid any issues due to ‘-’

Anyway, I have my .h with the correct definition

#define ni__actionpointid_loopback "loopback"

Moreover, when I try to configure using confd_cli I get the following:

localhost(config-network-instance-x)# loopback name hi
Error: not yet implemented

I assume the above is directly related to the error message found in confd_devel.log as below:

<ERR> 14-Jun-2019::16:54:48.329 localhost confd[843]: devel-c Daemon 'ConfdAdaptor' registered for non-existing actionpoint loopback

Please suggest something else.
Thanks in advance.

PS: I spent a minute finding the annotate without tailf:

Double check that you really have definition of actionpoint in executed fxs files/models.
Try running “confd --status” command in bash, and look into “actionpoints:” section, you should see something like this:
(I copy&pasted actionpoint names/status examples from ConfD example - intro/7-c_actions)

  id=reboot-point ** not registered

when you don’t have data provider registered, or, in case you already do:

  id=reboot-point daemonId=0 daemonName=actions_daemon callbacks=get_next,get_elem,exists

Actually, this error means exactly that there is no actionpoint in the model. If there is an actionpoint, but it hasn’t been registered for, you would get an “application communication failure” error when ConfD attemps to invoke your callback - the problem would also be logged with more details in the devel.log.

In that case it seems that this .h file was not generated from the .fxs that you are actually loading into ConfD. One possibility (rather far-fetched) for that could be that you generate the .h from the .yang file, using the annotation module, and then compile the .yang to .fxs without the annotation module:

$ confdc --emit-h ni.h -a ni-ann.yang ni.yang
$ confdc -c ni.yang
$ confdc --emit-h ni2.h ni.fxs
$ grep point ni*.h
ni.h:#define ni__actionpointid_loopback_point "loopback-point"

I.e. in that case there would be no actionpoint in the .fxs, as demonstrated by the ni2.h file not having the #define (while ni.h does). Please review the exact steps you are taking, starting with the .yang file, up to the point where you provide the .fxs file for ConfD to load.

Thanks. It works now.

If there is a 2 or more actionpoints, can i register in a only one registration operation?

Or how can i use it?

You can take a look at $CONFD_DIR/examples.confd/intro/7-c_actions for how registration works. When you register the callbacks for the action you call confd_register_action_cbs(). You can set up separate sets of callback functions for the different actions, and call this again for a second action. Once you are done registering all the actions that this application will handle, then you can call confd_register_done() so that ConfD knows that your application is finished with the registration, and the application is ready to begin processing actions.

Note too that in this example, the same actionpoint is used for multiple actions, so that you don’t need to necessarily have a separate action handler for each action.

1 Like