Swagger should identify config = true/false for the attributes in YANG

[HuiDingCATR]

Swagger should create two schema definitions for every YANG grouping (class）: 1) state attributes that contains all attributes; 2) config attributes that includes only config=true;

[karthik-sethuraman]

I guess this relates to an class/grouping having attributes that are input only, output only and both input/output

[rvilalta]

Hi Hui, do you have any example? Thanks.

[HuiDingCATR]

Hi Ricard,

Take grouping Topology and grouping ConnectivityService for example. The attributes in Topology are all "config false", so these attributes are read only and should only have "GET" operations in Swagger.

    grouping Topology {
        list _node {
            key 'uuid';
            config false;
            uses Node;
            description "none";
        }
        list _link {
            key 'uuid';
            config false;
            uses Link;
            description "none";
        }
        leaf-list layerProtocolName {
            type Tapi:LayerProtocolName;
            config false;
            description "none";
        }
        uses Tapi:ResourceSpec;
        description "The ForwardingDomain (FD) object class models the “ForwardingDomain” topological component which is used to effect forwarding of transport characteristic information and offers the potential to enable forwarding. 
            At the lowest level of recursion, an FD (within a network element (NE)) represents a switch matrix (i.e., a fabric). Note that an NE can encompass multiple switch matrices (FDs). ";
    }

In connectivityService, all the attributes except _connection is "config true" (which is not shown as default). So the other attributes, such as _servicePort, can have "POST/PUT/DELETE" operations.

    grouping ConnectivityService {
        leaf-list _connection {
            type leafref {
                path '/Tapi:Context/Tapi:_connection/Tapi:uuid';
            }
            config false;
            description "none";
        }
        list _servicePort {
            key 'localId';
            uses ConnectivityServicePort;
            description "none";
        }
        container _connConstraint {
            uses ConnectivityConstraint;
            description "none";
        }
        container _schedule {
            uses Tapi:TimeRange;
            description "none";
        }
        container _state {
            uses Tapi:AdminStatePac;
            description "none";
        }
        leaf direction {
            type Tapi:ForwardingDirection;
            description "none";
        }
        leaf layerProtocolName {
            type Tapi:LayerProtocolName;
            description "none";
        }
        uses Tapi:ServiceSpec;
        description "The ForwardingConstruct (FC) object class models enabled potential for forwarding between two or more LTPs and like the LTP supports any transport protocol including all circuit and packet forms.
            At the lowest level of recursion, a FC represents a cross-connection within an NE.";
    }

[rvilalta]

Dear Hui, The tooling takes into consideration config=false. If you find a concrete example where it is not taken into consideration, we might find a bug. I have not been able to find a bug example in the suggested ones:

-"/config/Context/_topology/{uuid}/_node/" has only get -"/config/Context/_topology/{uuid}/_link/" has only get

• "/config/Context/_connectivityService/{uuid}/_state/" has CRUD
• "/config/Context/_connectivityService/{uuid}/_connConstraint/" has CRUD

R.

[amazzini]

This issue has been closed due to the lack of activity for more than one year. Please reopen it if follow up is necessary.