How to implement multi-instance MO communicating with the same confd server?

I have the following yang data model for pppoe, I want to start multiple pppoe MOs to deal with different zone.

pppoe-A subscribes /pppoe-zones/zone{A} and /pppoe-zones/common-info
pppoe-B subscribes /pppoe-zones/zone{B} and /pppoe-zones/common-info
pppoe-C subscribes /pppoe-zones/zone{C} and /pppoe-zones/common-info

and all the ppoe MOs could start in the same server or in differen servers. If the common-info changed, it will notify all the pppoe MOs, and if zone{X} changed, it will only notify the pppoe-X.

Now current version of ConfD(6.1) works for config subscription on the same or different yang node in different instance of the same MO. All the MO could receive the configuration.

But it dose not work for callpoint, validation point, and actionpoint. So if different MO register the same xxxpoint, how to make it work? I mean how can I let pppoe-A register callpoint on /pppoe-zones/zone{A}/pppoe-show/, and pppoe-B register callpoint on /pppoe-zones/zone{B}/pppoe-show, and so on.

Instead of calling the callpoint in different MO on different entry of list, I also want confd call the callpoint with the same point name in all MOs.

grouping pppoe-model {
    container pppoe-config {
        leaf user {type string;}
        leaf pass {type string;}
        leaf auth {type string;}
        ...
    }
    container pppoe-show {
        config false;
        tailf:callpoint show-all;
        leaf sessions {type string;}
        leaf online {type string;}
    }
}

container pppoe-zones{
    list zone {
        key 'name';
        leaf name {type string;}
        uses pppoe-model;
    }
    leaf common-info {type string;}
}

You can make use of the set of confd_register_range_xxx_cb( ) callbacks in order to register for a range of list entries for callpoints, validation points, and action points. This allows you to register multiple sets of C functions under the same callpoint name and by different daemons.

The relevant API calls are as follows:

int confd_register_range_data_cb( );
int confd_register_range_valpoint_cb( );
int confd_register_range_action_cbs( );

You can refer to Volume 3 of the man pages under the confd_lib_dp section of the ConfD User Guide for descriptions on these API calls.

Hi wai, thanks!

The confd_register_range_xxx_cb() is suitable for process each entry in different daemon.

But, If I want to restart all the daemon with action restart, each daemon register the same action point, when users trigger it, all daemons will response on it.

container pppoe-zones{
    list zone {
        key 'name';
        leaf name {type string;}
        uses pppoe-model;
    }
    leaf common-info {type string;}
    tailf:action restart {
        tailf:actionpoint restart;
    }
}

The ConfD User Guide says that

If we want to
register for the same ranges in different lists, we must thus have a unique callpoint for each list

container pppoe-zones{
    list zone {
        key 'name';
        leaf name {type string;}
        uses pppoe-model;
    }
    leaf common-info {type string;}
    tailf:action restart {
        tailf:actionpoint restart_m1;
        tailf:actionpoint restart_m2;
        tailf:actionpoint restart_mN;
    }
}

Should I have make different actionpoint for different daemon(write yang like above)? If I have to, how about dealing with dynamic adding and deleting daemons?

If I understand your question correctly, you would like to be able to register for the same action from multiple daemons. If my interpretation is correct, there is currently no way to do that in ConfD. With your 1st YANG model, if you do multiple non-range registrations from different daemons, only the last one will take effect. With your 2nd YANG model, you can only define one actionpoint per action. The multiple actionpoints listed will result in an error by confdc. Perhaps you can designate a master daemon to be registered as the actionpoint that is responsible for restarting all deamons.

As for your second question, the action point daemons need to be running at all times in order for the action to be invocable through the northbound interfaces. If you delete one of the registered daemons, it will result in an error when the action is being invoked.

You’re right. This is exactly what I mean.

Thank you for suggestion, I’m trying to implement the master daemon to control other daemons.