Leaf Node in a CONTAINER cannot be deleted via RESTCONF HTTP DELETE Method

[sezerb]

Describe the bug
According to the RFC, I understand that if one can access a resource with GET, then it's a target resource.
I can get the content of a leaf node in a container with GET method, however I cannot delete it via DELETE method via RESTCONF.

Branch
lighty.io branch [14.0.x and 15.0.x]

To Reproduce
Steps to reproduce the behavior:

1. Setup a netconf server with tailf-d dhcpd yang example
2. Setup lighty-app-rnc
3. Register netconf server to lighty
4. Send a GET request ( http://localhost:8888/restconf/data/network-topology:network-topology/topology=topology-netconf/node=dhcp-test/yang-ext:mount/dhcpd:dhcp/default-lease-time ) and check it's working.
5. Send a DELETE request ( http://localhost:8888/restconf/data/network-topology:network-topology/topology=topology-netconf/node=dhcp-test/yang-ext:mount/dhcpd:dhcp/default-lease-time )
6. Result:

{
    "errors": {
        "error": [
            {
                "error-type": "application",
                "error-tag": "operation-failed",
                "error-info": "java.lang.IllegalStateException: Value has not been set",
                "error-message": "Transaction failed"
            }
        ]
    }
}

7. Send a DELETE request to http://localhost:8888/restconf/data/network-topology:network-topology/topology=topology-netconf/node=dhcp-test/yang-ext:mount/dhcpd:dhcp and the container will be deleted successfully.

So I cannot figure out that why it's not working for a leaf node while it's working for the container of the leaf node.

Expected behavior
The data shall be deleted. When I try it with a netconf client and edit configuration as below, it's working properly:
Request:

<dhcp xmlns='http://tail-f.com/ns/example/dhcpd' xmlns:nc='urn:ietf:params:xml:ns:netconf:base:1.0'>
  <default-lease-time nc:operation='delete'>
    PT300M
  </default-lease-time>
</dhcp>

Response:

<?xml version='1.0' encoding='UTF-8'?>
<ok xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"/>

Screenshots
Not applicable

Environment (please complete the following information):

• OS: [Linux EVT01479NB 5.4.72-microsoft-standard-WSL2]
• Java Version [11.0.11]
• Maven version [3.8.1]
• Please note that lighty-rnc-app is already containerized and running as a container.

Additional context
I come to this point while I was trying Yang-Patch to delete a leaf node. This is another yang module that we are using, but the structure is similar.
Yang-Patch request to: http://localhost:8888/restconf/data/network-topology:network-topology/topology=topology-netconf/node={{node}}/yang-ext:mount/dhcpd-kea:dhcp-kea/subnetscon/subnets={{subnet_uuid}}
Request Body:

{
    "ietf-yang-patch:yang-patch": {
        "patch-id": "delete-patch-1",
        "edit": [
            {
                "edit-id": "edit1",
                "operation": "delete",
                "target": "/dhcpd-kea:max-lease-time"
            }
        ]
    }
}

Response:

{
    "ietf-yang-patch:yang-patch-status": {
        "patch-id": "delete-patch-1",
        "errors": {
            "error": [
                {
                    "error-type": "application",
                    "error-tag": "operation-failed",
                    "error-message": "Transaction failed",
                    "error-info": "java.lang.IllegalStateException: Value has not been set"
                }
            ]
        },
        "edit-status": {
            "edit": [
                {
                    "edit-id": "edit1",
                    "ok": [
                        null
                    ]
                }
            ]
        }
    }
}

I'm pretty sure that the request body is OK for yang-patch, but again the problem is I cannot DELETE a leaf node in a container.

Appendix example dhcp yang module:

module dhcpd {

  namespace "http://tail-f.com/ns/example/dhcpd";
  prefix dhcpd;

  import ietf-inet-types {
    prefix inet;
  }

  import tailf-xsd-types {
    prefix xs;
  }

  organization "Tail-f Systems (a Cisco company)";

  contact "info@tail-f.com";

  description
    "YANG datamodel for ConfD Subscriber intro example
     (C) 2005-2018 Tail-f Systems

     Permission to use this code as a starting point hereby granted
     This is ConfD Sample Code.

     See the README file for more information";

  revision 2019-02-14 {
    description "Normalized YANG identifier names.";
  }

  revision 2018-11-20 {
    description "YANG header information updated";
  }

  revision 2009-05-19 {
    description "Initial revision.";
  }

  typedef loglevel {
    type enumeration {
        enum kern;
        enum mail;
        enum local7;
    }
  }

  grouping subnet {
    list subnet {
      key "net mask";
      leaf net {
        type inet:ipv4-address;
      }
      leaf mask {
        type inet:ipv4-address;
      }
      container range {
        presence "";
        leaf dynamic-bootp {
          type boolean;
          default false;
          description "Enable BOOTP for this instance.";
        }
        leaf low-addr {
          type inet:ipv4-address;
          mandatory true;
          description "Enable BOOTP for this instance.";
        }
        leaf high-addr {
          type inet:ipv4-address;
          description "Enable BOOTP for this instance.";
        }
      }
      leaf routers {
        type string;
      }
      leaf max-lease-time {
        type xs:duration;
        default PT7200S;
      }
    }
  }

  container dhcp {
    leaf default-lease-time {
      type xs:duration;
      default PT600S;
    }
    leaf max-lease-time {
      type xs:duration;
      default PT7200S;
    }
    leaf log-facility {
      type loglevel;
      default local7;
    }
    container subnets {
      uses subnet;
    }
    container shared-networks {
      list shared-network {
        key name;
        max-elements 1024;
        leaf name {
          type string;
        }
        container subnets {
          uses subnet;
        }
      }
    }
  }
}

Thanks in advance,
Sezer

[PeterSuna]

Hello Sezer,
I have verified that issue is present in lighty. Furthermore, I have tested
this issue in ODL Netconf 2.0.9 with netconf-testtool and found out
that same error is present in ODL. I have created and describe your issue
inside ODL Netconf Jira where you can track progress of resolving this problem.
https://jira.opendaylight.org/browse/NETCONF-831

Thanks for feedback.

[sezerb]

Hi Peter,
Thanks for reproducing the issue. I'll be following the ODL issue. I think we should leave this issue open. If it's fixed in the ODL side then we can look forward to having ODL official release in lighty.io release train. Do you have a guess about how long would it take? (I know that ODL gives releases twice a year)

Regards,
Sezer

[ihrasko]

Fixed in Lighty.io 15.2.0

Enjoy!