How to only get object's configured node

Hi,
I configure “contexts context 11” and “commit”. In my application, I deal with the command in preprare phase by two phase mode, I access “/contexts/context{11}” object’s child node from the cdb by data sock with the following sequence of functions, confd_cs_node_cd(), confd_max_object_size(), cdb_get_object(), confd_next_object_node(), but it will iterate out all node in this object, the result likes the following,
node:kp=/contexts/context{11}/context-name
node:kp=/contexts/context{11}/subscriber
node:kp=/contexts/context{11}/ip
node:kp=/contexts/context{11}/ipv6
node:kp=/contexts/context{11}/router

We didn’t configure ip, ipv6 etc, but it iterate out these node . these nodes are those I didn’t configured,
we hope if we configure the router under context 11, for example “router ospf 1”, then the router can be iterated out.

is there a way to get only configured node?

You can use the cdb_diff_iterate( ) API call to iterate over the changes after reading the subscription socket. You can refer to examples.confd/cdb_subscription/iter_c for the example code.

hi waitai,
Thanks waitai, perhaps it is not clear in my topic, I mean I need to only get the node that user have configured before, not just the current commiting. The cdb_diff_iterate() can only get the configuration that the user commit this time.

When cdb_diff_iterate( ) is called, you can set the flags parameter to ITER_WANT_PREV. This allows oldv to be pointing to the configuration values prior to the commit operation.

Refer to the confd_lib_cdb section in Volume 3 of the ConfD man-pages for more information on cdb_diff_iterate( ). There is also an example under examples.confd/cdb_subscription/iter_c that makes use of the ITER_WANT_PREV flag of cdb_diff_iterate( ).

Hi waitai,
please ignore the diff, i access the cdb with data sock, I need to get the configuration from cdb, i didn’t config the subscriber,ip, ipv6 under context 11 before, when I get the child of context 11, i can get the nodes of subscriber, ip and ipv6, i hope we can’t get these nodes as we didn’t configure them before.
node:kp=/contexts/context{11}/context-name
node:kp=/contexts/context{11}/subscriber
node:kp=/contexts/context{11}/ip
node:kp=/contexts/context{11}/ipv6

If I understand your question correctly that you are using the full set of CDB API calls to access the data stored in CDB. When you access the CDB APIs directly to access the configuration data, you will have full access to all configuration data stored in CDB. There is nothing that will prevent you from being able to access configuration data that may have been configured in the past. The only way to restrict that is to use cdb_diff_iterate( ) or cdb_diff_match( ) to find out what has changed.

Hi waitai,
When we access the old configuration of a node, we hope we can only get the node’s children that user has been configured before.
For example, on a clean node:
first time:
contexts context 1
commit

second time:
contexts context 2
commit

In the second time, in prepare phase, we need to acess old configuration of context 1 node. When we get context 1’s children ( cdb_get_object(/contexts/context{1}) ), we find we get the “subscriber” too. But we never configured it before. Our expectation is that we cannot any node we haven’t configured.

Here are the yang models:

contexts.yang:

container contexts {
description
“root model for set”;

context.yang:

augment “/ctxsipos:contexts” {
description
“ericsson-context”;
list context {
key “context-name”;
description
“Configure an operational context”;
leaf context-name {
type string;
description
“Specify a named context to configure”;
}
container subscriber {
description
“Configure subscriber accounts and options”;
list name {
key “name”;
description
“Configure individual subscriber accounts”;
leaf name {
type string;
description
“subscriber account name”;
}
}
}

You will be able to access the subscriber container without configuring it if you have any leaves in it that have default values.

Hi waitai,
In the mode, there are no default value in all leaves of subscriber,Is there a way can meet our requirement

I can’t think of anything else to suggest based on what you have stated so far in this posting. At this point, it is best for you to submit this issue with our support team by filing a RT through your account.

Hi waitai,
Do you know how confd cli “show running-configuration” is implemented? In that command we don’t see unconfigured nodes.