ConfD 6.3 Linuxcfg & YDK update/create, commit fails


While trying to perform a modification of a ConfD 6.3 example linuxcfg with NETCONF (call done using YDK and Crud service) - I am getting an error after a commit.

Modfication of a config:

"<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <config><interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge">
  <interface nc:operation="merge">
    <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:gigabitEthernet</type>

It is accepted by ConfD:

"<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3">

Then crud tries to commit:

"<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4">

And it fails:

"<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"><rpc-error>
<error-path xmlns:sys="urn:ietf:params:xml:ns:yang:ietf-system">
  </error-path><error-message xml:lang="en">application error</error-message><error-info><bad-element>contact</bad-element>

Editing the candidate without using <lock> is generally a bad idea - to quote RFC 6241: It is therefore prudent for a client to lock the candidate configuration before modifying it. If you don’t use <lock>, changes from other sessions may be left in the candidate, and when you <commit>, all the changes will commited (if possible).

In this case there is apparently some change to /sys:system/sys:contact (in ietf-system.yang), and one of your DP-API callbacks is unhappy with it. You can find the “application error” in $CONFD_DIR/src/confd/errors/errcode.xml (see the section Error Message Customization in the Advanced Topics section of the User Guide):

<code name="application" errno="CONFD_ERR_EXTERNAL">
    application error
    This error denotes an unspecified error, generated by an
    application.  Typically, when the application generates this
    error, it generates an application-specific error string,
    which is presented to the user.

Basically, the literal “application error” message is provided to the northbound interface if your callback returns CONFD_ERR without first providing specific info via one of the confd_trans_seterr*() functions.