[NETCONF-581] restconf to netconf translation doesn't honor the order of the keys for lists with multiple keys Created: 13/Nov/18  Updated: 26/Dec/19  Resolved: 26/Dec/19

Status: Resolved
Project: netconf
Component/s: netconf
Affects Version/s: None
Fix Version/s: Neon SR3, Magnesium, Sodium SR2

Type: Bug Priority: Medium
Reporter: Steven Van Hoof Assignee: Steven Van Hoof
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates YANGTOOLS-1037 Mis-ordered keyed list children in NE... Resolved

 Description   

Yang snippet of my device:

module ibn { 
  namespace "http://www.nokia.com/management-solutions/ibn";
  prefix "ibn";
  import ietf-yang-types { prefix yang; }
  import ibn-administration { prefix ibn-administration; }

  organization "Nokia";
  revision "2017-11-28" {

    description "Initial version.";
    reference "ibn";
  }
 
  container ibn {
    list intent {
      key "target intent-type";
      leaf target {
        type string {
          length "1..300";
        }
        mandatory true;
        description "Uniquely identifies an intent within an intent-type";
      }
      leaf intent-type {
        type leafref {
          path "/ibn-administration:ibn-administration/ibn-administration:intent-type-catalog"
             + "/ibn-administration:intent-type/ibn-administration:name";
        }
        mandatory true;
        description "Name of the intent type";
      }
[...] 

 

So we have a list of intents with two keys.

 

When I create an entity through the ODL restconf API I pass the following body:

{
  "intent":
  {
    "target": "test4",
    "intent-type": "sddpu-cfas-h-infra",
    "configuration": {
      "sddpu-cfas-h-infra:sddpu-cfas-h-infra": {
      "mcast-network-vlan": 1002
    }
  },
  "sync-directly": false,
  "intent-type-version" : 1
  }
}

 

However what comes out is:

 

<rpc message-id="m-19" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <edit-config>
 <target>
 <running/>
 </target>
 <error-option>rollback-on-error</error-option>
 <config>
 <ibn xmlns="http://www.nokia.com/management-solutions/ibn">
 <intent xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0" a:operation="replace">
 <intent-type>sddpu-cfas-h-infra</intent-type>
 <target>test4</target>
 <sync-directly>false</sync-directly>
 <configuration>
 <sddpu-cfas-h-infra xmlns="http://www.nokia.com/management-solutions/sddpu-cfas-h-infra">
 <mcast-network-vlan>1002</mcast-network-vlan>
 </sddpu-cfas-h-infra>
 </configuration>
 <intent-type-version>1</intent-type-version>
 </intent>
 </ibn>
 </config>
 </edit-config>
 </rpc>
 , response: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-19">
 <rpc-error>
 <error-type>application</error-type>
 <error-tag>missing-element</error-tag>
 <error-severity>error</error-severity>
 <error-path xmlns:ibn="http://www.nokia.com/management-solutions/ibn">/ibn:ibn/ibn:intent[ibn:intent-type='sddpu-cfas-h-infra'][ibn:target='test4']</error-path>
 <error-message>Expected list key(s) [target, intent-type] is not placed in the proper location in the message</error-message>
 <error-info>
 <bad-element>target</bad-element>
 <bad-element>intent-type</bad-element>
 </error-info>
 </rpc-error>
 </rpc-reply>

 

So the keys are swapped

 



 Comments   
Comment by Jamo Luhrsen [ 10/Dec/19 ]

for completeness copy/paste from an email request that hit netconf-dev alias from kowsalyasaravanan@gmail.com :

Hi Steven,
We need some additional information/steps to reproduce the issue NETCONF-581. We are planning to include the given yang that contains list with two keys in sodium and trying to reproduce it. Please let us know if there is any other way to reproduce it.
Thanks
Comment by Robert Varga [ 11/Dec/19 ]

Also, which version is this encountered with? It smells related to https://jira.opendaylight.org/browse/YANGTOOLS-1037 ...

Comment by Kowsalya Saravanan [ 16/Dec/19 ]

This issue is similar to YANGTOOLS-1037.

In YANGTOOLS-1037, tenant-id to be encoded first rather than access-control-list-id as per key order defined in yang. Device throwing error during delete operation:
In NETCONF-581, target to be encoded first rather than the intent-type as per key defined in yang. Device throwing error during replace operation.
In YANGTOOLS-1037, already the logic has been modified to recreate the NodeIdentifierWithPredicates if the provided order doesn't match it.
ImmutableOffsetMap is used which is guaranteed to be taken as-is. This seems to be a duplicate one.
Robert - Please review and provide your feedback on this. 

Comment by Robert Varga [ 26/Dec/19 ]

svanhoof this looks like a duplicate of YANGTOOLS-1037 and KowsalyaChandru 's testing indicates that the issue is fixed in current snapshots (Neon SR3/Sodium SR2/Magnesium).

Please confirm that is the case and if not, please reopen this issue.

Generated at Wed Feb 07 20:15:23 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.