[NETCONF-860] Some BBF yang devices using actions have invalid swagger URLs generated. Created: 09/Feb/22  Updated: 27/Jun/23  Resolved: 27/Jun/23

Status: Resolved
Project: netconf
Component/s: restconf-openapi
Affects Version/s: None
Fix Version/s: 6.0.0, 5.0.7, 4.0.9

Type: Bug Priority: Medium
Reporter: Robert Magaldi Assignee: Yaroslav Lastivka
Resolution: Done Votes: 0
Labels: pt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File Steps to reproduce.odt     File bbf-hardware@2020-10-13.yang     File bbf-software-management@2021-09-17-1.yang     File bbf-yang-types@2020-05-11-1.yang     File iana-hardware@2018-03-13-1.yang     File ietf-hardware@2018-03-13-1.yang     File ietf-inet-types@2013-07-15-1.yang     File ietf-interfaces@2018-02-20.yang     File ietf-netconf-monitoring-extension@2013-12-10-1.yang     File ietf-netconf-monitoring@2010-10-04-1.yang     File ietf-yang-types@2013-07-15-1.yang     PNG File image-2022-02-09-16-29-06-094.png     Zip Archive test-schemas.zip    
Issue Links:
Relates
relates to NETCONF-1021 OpenAPI: Do not hardcode action path Resolved

 Description   

This problem was discovered in Lighty.io version14.0 and version15.1 - which can be seen on ODL versions Silicon and Phosphorus SR1. 

It seems that some BBF (Broadband Forum) yang files that include "actions" construct invalid "POST" urls in the swagger. 

This is an extension to NETCONF-859.  The same yang files are included in this JIRA, HOWEVER, the bbf-software-management yang has been modified to work with swagger (workaround for NETCONF-859). The version of the yang included here is the same, but the file content differs slightly to address NETCONF-859. The delta in the bbf-software-management yang file is shown below - the leafref path was changed to the actual definition. 

928c928,930
< type uint8;

> type leafref

{ > path "../../../../../../../bbf-swm:revisions/bbf-swm:revision/bbf-swm:id"; > }

968c970,972
< type bbf-yang:string-ascii64;

> type leafref

{ > path "../../../../../../../bbf-swm:revisions/bbf-swm:revision/bbf-swm:alias"; > }

Inside the yang file, there is an action called "download" which exists in a container called "download":
container download {
when "boolean(../../capability='bbf-swm:download') and count(../revision[state='downloading'])=0"

{ description "Only applicable if the 'download' capability is supported and no other download of a revision is in progress for this software."; }

presence "Downloading of revisions for this software is
enabled.";
config false;
description
"Provides containment for the action 'download'.";
action download {
if-feature "software-actions";
description
"Download the specified software revision to this
component.
....

The bbf-software-manager yang augments ietf-hardware. Under ietf-hardware we can see that the URL for the "download" above is messed up.

The picture of this is attached.
The URL shown/generated is
rests/operationsata/network-topology:network-topology/topology=topology-netconf/node-myDevice/yang-ext:mount/ietf-hardware/component=

{name}/bbf-software-management:software/software={name1}/revisions/download/download

The beginning of the generated URL should be /restconf/operations/...

Also included in this set of yang files is the bbf-hardware yang file which includes a "reset" action. The yang may be easier to look at for this one. It also is an "action" to do a reset, and it also contains a URL that is messed up.

rests/operationsata/network-topology:network-topology/topology=topology-netconf/node=myDevice/yang-ext:mount/ietf-hardware:hardware/component={name}

/bbf-hardware:reset

To recreate this, use netconf testtool to create a device simulator using all the yang models attached to this JIRA. The device will get mounted. Go into swagger and you will notice that the two mentioned generated URLs which are POST requests for underlying "actions" have bad URLs. Also, there is no parameters - each URL has some parameters, but the parameters section in the swagger does not show any.

 



 Comments   
Comment by Ivan Hrasko [ 03/May/23 ]

The following is not an issue: "The beginning of the generated URL should be /restconf/operations/..." because currently ODL supports RFC8040 only (/rests/). Even if you are using the previous releases we can see from URLs (key values are inserted by =) that you are using RFC8040 implementation.

Comment by Ivan Hrasko [ 03/May/23 ]

It looks that action examples are missing "parameters" section.

Comment by Ivan Hrasko [ 03/May/23 ]

In the previous releases there was also problem with choices NETCONF-983 which is now solved.

Comment by Ivan Hrasko [ 21/Jun/23 ]

One one small problem is that paths should start with "/".

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