Setting "no" to leaf deletes entire list

Model is having a leaf node with default value “true”.
When I give the “no” form of configuration it is deleting the list entry instead of setting “flase” to the leaf node.

Model example:

container box{
	list Item {
		key "name";
 		leaf name{
			type string;
		container element {
			leaf leaf_name {
				type boolean;
				default "true";

the config is :

box item item_name element leaf_name

If I give “no box Item item_name element leaf_name” it is not setting the “false” to the leaf.

Instead, it is deleting the list item. How to make “no” command, in this case, to set “false” to leaf node instead of deleting the list?

Confd generated XML for the “no” form of config.

    <item operation="delete">

Do you insist on all those tailf:cli-... statements? The combination of them is most likely what confuses ConfD. I don’t see anything that is outright prohibited, but do you need all of them, cannot you drop, for instance, the cli-delete-when-empty statement?

thanks for your reply. cli-delete-when-empty is needed here, without that we have empty list configuration on CONFD. the empty list configuration is not accepted by device cli. Also when we delete the top level container box that empty list command creates problem in device cli.
Is there any other way to set false to the end leaf ?

As @mvf points out, tailf:cli-delete-when-empty deletes the list entry.

  1. You seem to be using cdb_get_modifications() to “generate” XML according to the “examples.confd/cdb_subscription/modifications”. You will not get deleted children in a list entry from cdb_get_modifications() when you delete it.
  2. You have set the default value of “leaf_name” to “true”, so the resulting config will always be “true” (never “false”) when you delete “leaf_name”.

So you want to prevent empty lists. But delete-when-empty does not really help you with that. First, it only works on deletion, it does not do anything to prevent that the list is created empty. Second, it works only for CLI, and of that only for C- and I-style CLI; but you may want to assure this for other interfaces or other means of configuration.

What about stating your requirement using must? It might be a bit less convenient for a CLI operator, but more robust, in my opinion.