Query on confd validation when confd_err is returned

CDB and CDB API
1

Hi,

I have a scenario where I need to have a validation.
I have used confd validation and return CONFD_VALIDATION_WARN or CONFD_ERR when required.
When CONFD_VALIDATION_WARN everything is ok but when CONFD_ERR is returned the behaviour is weird.

When CONFD_ERR is returned and if a new command is given on the cli, I still the get the old values.
For example
I gave a command “add” in CLI and threw CONFD_ERR during validation next if I give “delete”, the back end listener/subscriber still the gets the values of “add” instead of “delete”.

2

This is a bit too brief for us to understand the problem. Can you show relevant parts of your data model so that we can know what “add” or “delete” can mean? Possibly also the CLI commands that behave differently from what you would expect?

But generally: validation failure does not mean that the configuration changes are discarded - they are preserved, and it is up to the operator to change the configuration so that it becomes valid again.

3 
    container kh {
        container add-host {
            tailf:validate kh_validation {
                tailf:dependency '.';
            }
            leaf remote-hostname {
                type string;
            }
            leaf fingerprint {
                type string;
            }
        }
        container delete-host {
            leaf remote-hostname {
                type string;
            }
        }
    }

simulator-1(config)# kh add-host remote-hostname 10.145.77.333

simulator-1(config)# commit

Aborted: ‘kh add-host remote-hostname ’: Host un-reachable

—> Here validation throws a confd_err due validation failure

simulator-1(config)# kh delete-host remote-hostname 1.1.1.1

simulator-1(config)# commit

For this operation in the subscriber I get the values/data of “kh add-host remote-hostname 10.145.77.333” instead of “kh delete-host remote-hostname 1.1.1.1”

I am looking for the possibilities on how to discard the changes/configurations done as part of add-host in case of validation-failure

4

As I wrote - the configuration is not altered in any way in case its validation fails. In general it is not easy or even possible to correctly identify what exactly is wrong with the configuration, therefore it is the left to the operator to make necessary changes.

In your case, if after doing kh delete-host remote-hostname 1.1.1.1 you checked how the configuration looked like, this is what you would have likely got:

simulator-1(config)# kh delete-host remote-hostname 1.1.1.1
simulator-1(config)# show config
kh add-host remote-hostname 10.145.77.333
kh delete-host remote-hostname 1.1.1.1
simulator-1(config)#

As you can see, the configuration still consists of the add-host part, and now it also contains delete-host part. When the validation callback is invoked, the add-host part is checked first because it precedes the other part in the data model; since your callback refuses to validate this configuration, no further checks are done.

I suspect you misunderstood the concept of “data model” and “configuration”. A data model describes what a system configuration should consist of, it does not describe how to create such configuration. A typical data model rarely contains verbs such as add or delete. So as to describe that my system’s configuration consists of a list of remote hosts and their fingerprints, the data model might look like

container hosts {
  list host {
    key hostname;
    leaf hostname {
      type string;
    }
    leaf fingerprint {
      type string;
    }
  }
}

And in a configuration session I might do something like

box(config)# hosts host 10.145.77.333
box(config-host-10.145.77.333)# top
box(config)# commit
Aborted: 'hosts host 10.145.77.333 hostname': Host unreachable
box(config)# show config
hosts host 10.145.77.333
!
box(config)# no hosts host 10.145.77.333
box(config)# show config
% No configuration changes found.
box(config)#