[MDSAL-63] Datastore / Restconf / Data Broker should optionally support "default" statement Created: 08/Dec/14 Updated: 09/Jan/24 |
|
| Status: | Confirmed |
| Project: | mdsal |
| Component/s: | Binding runtime, DOM API, DOM runtime |
| Affects Version/s: | None |
| Fix Version/s: | 14.0.0 |
| Type: | Improvement | ||
| Reporter: | Reinaldo Penno | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||||||
| Description |
|
Yang leaf default statement is not honored by Yang/datastore I have the following in a model
leaf symmetric {
type boolean;
default false;
description "If the chain is symmetric we will create two service paths, one ingress and another egress. Packets traverse the egress service path in the reverse order of the ingress path";
}
If a create new container and do not pass a value for leaf "symmetric" I expect "false" to be assigned. But this does not happen. If I read the container and try to check the value of "symmetric" from datastore I get a NULL pointer exception: if (serviceFunctionChain.isSymmetric()) { } And serviceFunctionChain is not NULL. All values are properly there with exception of "symmetric" ServiceFunctionChain{getName=SFC2, getSfcServiceFunction=[SfcServiceFunction\{getName=firewall-abstract2, getOrder=0, getType=class org.opendaylight.yang.gen.v1.urn.cisco.params.xml.ns.yang.sfc.sft.rev140701.Firewall, augmentations={}}, SfcServiceFunction\{getName=napt44-abstract2, getOrder=1, getType=class org.opendaylight.yang.gen.v1.urn.cisco.params.xml.ns.yang.sfc.sft.rev140701.Napt44, augmentations={}}], augmentations={}} |
| Comments |
| Comment by Tony Tkacik [ 08/Dec/14 ] |
|
Data Broker APIs / Data APIs should provide an option to user to create data YANG itself does not mandate honoring "default" statements, just captures them and MD-SAL itself is not Netconf (specified via additional capability) nor Restconf, so this is new feature request. Default statements are already supported by config models in Config subsystem. |
| Comment by Shaleen Saxena [ 18/Sep/15 ] |
|
So what is the plan to fix MDSAL-63? If ODL claims to be a commercial level product and needs to be deployed in Service Provider or Large Enterprise markets, then we need to support all aspects of YANG. Having customers or individual apps deal with handling of default will make adoption of ODL harder. |
| Comment by Colin Dixon [ 13/Oct/15 ] |
|
There was a long discussion about this on the MD-SAL weekly interest call today. There are meeting minutes here: The implication of the discussion seemed to be that default values could not be actually stored in the data store and returned normally while honoring the spec based on some clarification in RFC6243 which provides methods (for NETCONF) that allow for reads which need to explicitly contain the default nodes. For what it's worth, it's not clear to me on reading RFC6243 what the correct behavior is. It seems more than RFC6243 notes that different NETCONF implementations have done different things, which has complicated development, so there's an extension to NETCONF to allow for the behavior to be more explicit. Along those lines, unless I'm missing something else, I don't see the spec as forbidding us from creating default nodes. |
| Comment by Robert Varga [ 30/Sep/20 ] |
|
Okay, my long analysis got lost, sorry. There are four views of data, each having different trade-offs:
The crux of the problem is differentiating when a value is default and when it is explicit in binding APIs. We also need to deal with copy constructors. At the end of the day we want two different access methods, one for explicit, on for explicit-or-implicit values – obviously within binding spec limitations. RESTCONF has enough information to know what the user wants, hence it knows how to fake it, and this should have little problem complying. |