Open-Network-Models-and-Interfaces-ONMI
UUID vs. tree structured data model
As agreed on https://wiki.opennetworking.org/display/OTCC/2019-05-21+TAPI+Meeting+Notes:
- TAPI yang currently does not include any Yang 1.1 features/modules - so we can state that we use 1.0
- As far as using leafref within a read-write tree to point to read-only attributes, we should use Yang 1.1 require-instance, but if we want to stick to Yang 1.0, we can use uuid instead of leafref
- Decision: Replace pointer references in TopologyConstraint with UUID references for both 2.1.2 as well 2.2.0.
This decision may cause issues as far as TAPI uses YANG to define the data model, which is a tree structured data model, so naturally the first choice during the TAPI implementation would be a tree datastore. Since it’s a tree datastore, to access a subtree its always required to pass all the parent keys in order to reach the subtree. Even the TAPI YANG model expects the same while accessing all objects. Both the model driven RESTCONF API and the RPC, e.g. in "[email protected]" to access a Node Edge Point from a given Topology and a given Node, the following are the RESTCONF and the RPC API structures : /tapi-common:context/tapi-topology:topology-context/topology/{uuid}/node/{uuid}/node-edge-point/{uuid} rpc get-node-edge-point-details
However, while providing the constraints during connectivity service provisioning, this hierarchy has been removed in TAPI 2.2 (which was available in TAPI 2.1) and only the leaf UUID is expected for each constraint. If the implementation is having a tree datastore, it would not be possible to access the leaf object to get its details, unless the UUIDs for each of its parent is provided.
@amazzini : has this change be included in TAPI 2.1.2 which has been just released?
https://github.com/OpenNetworkingFoundation/TAPI/releases/tag/v2.1.2
Since the issue is related to YANG 1.0 versus YANG 1.1, why should be change the UML model rather than the UML2YANG translation rules?
TAPI yang currently does not include any Yang 1.1 features/modules - so we can state that we use 1.0
@karthik-sethuraman : I think it would be worthwhile mentioning this point in the Release Notes (I would start from the next release)
This issue has been closed due to the lack of activity for more than one year. Please reopen it if follow up is necessary.