Iteration on notifications

  1. Is there a way to not iterate and get all the information from the poll socket in one shot rather than in pieces ( which we get through the iter function).
    The benefit with cdb_diff_iterate() is that it also gives us a notion of the diff , which we will lose if we try to go and read from CDB through read sockets ( we are not having any in-memory data also which we could have used to identify the diff) .
    So we want to retain that benefit also .
    This query is coming because we want to make sure that if a transaction has multiple configurations (multiple commands in one transaction ) , we want to collect the data of all of them and in one shot send it to our switch . With this we want to ensure that the transaction either succeeds or fails in its entirety. We are not able to design our system to satisfy this requirement with the usage of the cdb_diff_iterate() api.

  2. We have a YANG model that has both CDB data and external database data. Now let’s say there is a transaction that has multiple commands ( same as above ) and few commands are for external data store and few for CDB. Even in this case we want to ensure that when we are pushing configurations into our switch , we should be able to do it in one shot.
    Basically is there a way through which in our application before handling notifications or set_elem() calls, we get a notion of what kind of data is coming in the transaction ( is it just CDB type of data or is it a mixture of CDB and external data ). If this information is there , we can then make sure that we wait for both - notification apis and set_elem() apis to finish and then in one shot push configurations to our switch.


For question #1, there is cdb_get_modifications() call that you can make to get all the configuration changes at once. You can also get the modifications in the form of CLI commands, if that makes it easy to feed to your platform, by using the cdb_get_modifications_cli() API call.

For question #2, the CDB and DP API are going to work independently of each other so there is no built in way to co-ordinate the two, as you have for example by using the priority mechanism in subscribe() in the CDB API.

One way that you may be able to at least get the information from the CDB subscribers to the data provider, would be to have the CDB subscribers use a two phase subscription so that they are notified during the prepare phase in addition to the commit phase. The CDB subscribers get the changes during the prepare phase and put the information somewhere for the data provider (could be shared memory, a message queue or any other mechanism that you can think of). Then when the data provider gets the commit callback, it checks for the data from the CDB subscribers, merges the two sets of changes together and sends the information to the switch.

Thanks Greg for the answers.