https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/MDSAL-63 mdsal <p>Yang leaf default statement is not honored by Yang/datastore</p> <p>I have the following in a model</p> <p> </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>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"; } </pre> </div></div> <p> </p> <p>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.</p> <p>If I read the container and try to check the value of "symmetric" from datastore I get a NULL pointer exception:</p> <p>if (serviceFunctionChain.isSymmetric()) {</p> <p>}</p> <p>And serviceFunctionChain is not NULL. All values are properly there with exception of "symmetric"</p> <p>ServiceFunctionChain{getName=SFC2, getSfcServiceFunction=<span class="error">&#91;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={}}&#93;</span>, augmentations={}}</p> <p>Operating System: All<br/> Platform: All</p> MDSAL-63

Datastore / Restconf / Data Broker should optionally support "default" statement

Improvement Confirmed Unresolved Unassigned Reinaldo Penno Mon, 8 Dec 2014 01:53:30 +0000 Tue, 9 Jan 2024 09:15:23 +0000 14.0.0 Binding runtime DOM API DOM runtime 0 10 <p>Data Broker APIs / Data APIs should provide an option to user to create data<br/> with defaults on (e.g. Netconf capability described in <a href="https://tools.ietf.org/html/rfc6243" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/rfc6243</a>)</p> <p>YANG itself does not mandate honoring "default" statements, just captures them and<br/> mapping to particular system deals how defaults are processed.</p> <p>MD-SAL itself is not Netconf (specified via additional capability) nor Restconf, so this is new feature request.</p> <p>Default statements are already supported by config models in Config subsystem.</p> <p>So what is the plan to fix <a href="https://jira.opendaylight.org/browse/MDSAL-63" title="Datastore / Restconf / Data Broker should optionally support &quot;default&quot; statement" class="issue-link" data-issue-key="MDSAL-63">MDSAL-63</a>? 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.</p> <p>There was a long discussion about this on the MD-SAL weekly interest call today. There are meeting minutes here:<br/> <a href="https://meetings.opendaylight.org/opendaylight-meeting/2015/md_sal_interest_call/opendaylight-meeting-md_sal_interest_call.2015-10-13-16.44.html" class="external-link" target="_blank" rel="nofollow noopener">https://meetings.opendaylight.org/opendaylight-meeting/2015/md_sal_interest_call/opendaylight-meeting-md_sal_interest_call.2015-10-13-16.44.html</a></p> <p>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.</p> <p>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.</p> <p>Along those lines, unless I'm missing something else, I don't see the spec as forbidding us from creating default nodes.</p> <p>Okay, my long analysis got lost, sorry. There are four views of data, each having different trade-offs:</p> <ol> <li>DOM, where we never want to see derived defaults</li> <li>yang-binding builders, where we cannot have 100% coverage due to 'default' being an instantiation-override function. Since groupings are reused, we cannot have them implement defaults accurately.</li> <li>DOM-based proxies, which have access to both 1. and 2. (in principe)</li> <li>NETCONF/RESTCONF access</li> </ol> <p>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.</p> <p>RESTCONF has enough information to know what the user wants, hence it knows how to fake it, and this should have little problem complying.</p> Duplicate YANGTOOLS-455 YANGTOOLS-507 Development External issue ID 2489 External issue URL Issue Type ODL SR Target Milestone Priority Rank 0|i02w33: