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/CONTROLLER-644 controller <p>I have 2 yang files when constructing a system entity:</p> <p>The main file a "system.yang" where the entity-fields are defined, and configuration file "system-config.yang" that provides an augmentation to configuration with binding-broker, data-provider and rpc-registry containers inside (standard definition):</p> <p>augment "/config:modules/config:module/config:configuration" {</p> <p>An additional container is appended after "container rpc-registry" e.g.</p> <p>container entity-config {<br/> uses system:entity-fields;</p> <p> leaf description </p> { type string; } <p> <br/> }</p> <p>If I removed the "leaf description" from the "system-config.yang", I'm getting a following ERROR. If the "leaf description" remains no ERROR is thrown and entity's fields are generated:</p> <p><span class="error">&#91;ERROR&#93;</span> Failed to execute goal org.opendaylight.yangtools:yang-maven-plugin:0.6.2-SNAPSHOT:generate-sources (default) on project ..: yang-to-sources: One or more code generators failed, including failed list(generatorClass=exception) </p> {org.opendaylight.controller.config.yangjmxgenerator.plugin.JMXGenerator=java.lang.IllegalStateException} <p> -&gt; <span class="error">&#91;Help 1&#93;</span></p> <p>Question is why there should be an additional leaf defined?</p> <p>Operating System: Windows<br/> Platform: PC</p> CONTROLLER-644

JMXGenerator IllegalStateException when referring a Grouping from augmented model

Bug Resolved Done Maros Marsalek Miloslav Radakovic Thu, 24 Jul 2014 09:52:40 +0000 Tue, 25 Jul 2023 08:24:01 +0000 Wed, 30 Jul 2014 10:24:01 +0000 config 0 4 <p>Hi, </p> <p>I think there should be no reason for a failure when you remove the description node. </p> <p>Do you have your yang schemas available somewhere ? e.g. Draft in gerrit ?</p> <p>Could you give me a pointer to that so I can reproduce/debug/fix this issue ?</p> <p>Thanks,<br/> Maros</p> <p>Attachment test.zip has been added with description: TestCase-JMXGenerator Error</p> <p>Hi, <br/> I don't have yang schemes in Gerrit, I can't provide them right now so I prepared a simple test case (enclosed attachment) where mentioned lines are commented ("sys-entity-conf.yang") and the ERROR is generated:</p> <p>container sys-entity-config {<br/> uses sysent:sys-entity-fields; </p> <p> //leaf description-config </p> { //type string; //} <p> <br/> }</p> <p>If uncommented, build "mvn clean install" is OK.</p> <p>Regards,<br/> M</p> <p>Thank you for the test input.</p> <p>I have fixed the problem here <a href="https://git.opendaylight.org/gerrit/#/c/9423/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/9423/</a>. Setting to waiting-for-review.</p> <p>There was a problem with the code generator for config subsystem. When using a container with one uses in yang, the generator assumed a dependency. Added a better check for dependency containers.</p> <p>Maros</p> <p>Thanx for the fixing.</p> <p>Now I have an additional problem related to Yang parser. The same test case holds but in the "sys-entity" yang model I'm using "sys-entity-fields" only with the choice statement: </p> <p>grouping sys-entity-fields {<br/> choice version {<br/> case v1 {<br/> leaf value </p> { type string; } <br/> }<br/> case v2 {<br/> leaf value { type string; } <p> <br/> }<br/> }<br/> }</p> <p>In this case the same ERROR is generated if I reference to entity's fields from augmented configuration model, i.e.</p> <p>In "sys-entity-conf.yang" file</p> <p>augment "/config:modules/config:module/config:configuration" {<br/> case sys-entity {<br/> when "/config:modules/config:module/config:type = 'sys-entity'";</p> <p> .. binding-broker, data-provider, rpc-registry ..</p> <p> container sys-entity-config </p> { uses sysent:sys-entity-fields; } <p> }<br/> }</p> <p>If I remove the container from the augmentation, no ERROR is generated and build is OK, i.e. </p> <p>augment "/config:modules/config:module/config:configuration" {<br/> case sys-entity </p> { when "/config:modules/config:module/config:type = 'sys-entity'"; .. binding-broker, data-provider, rpc-registry .. } <p>}</p> <p>container sys-entity-config {<br/> uses sysent:sys-entity-fields; <br/> }</p> <p>Now it seems that the ODL controller provides two different parsers or validators for the YANG language? One for not augmented and one for augmented models? I don't think this is correct from the architecture point of view.</p> <p>About the two parsers:</p> <p>Its not that ODL has 2 parsers (one for augment, one for non-augment). There is only one parser that parses the schema. However, config subsystem has its own code generator on top of schema parsed by yangtools, it only looks and validates some nodes from the schema that are tied to config subsystem. Thats why it did not fail when you put the container outside of the augmentation (It was ignored by config subsystem).</p> <p>What you report is a new bug, already reported:<br/> <a href="https://bugs.opendaylight.org/show_bug.cgi?id=1451" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=1451</a></p> <p>Changing status of this back to FIXED. The new bug will be tracked in 1451.</p> <p>Maros</p> <p>And about using choices in configuration.</p> <p>It is not supported. Config subsystem and its generator supports only a subset of yang statements that can be used for configuration and those are:</p> <p>leaf, leaf-list, container, list</p> <p>So failing with choices under configuration augment is expected. This limitation is related to JMX usage in config subsystem. Statements other then those mentioned above are difficult to map to JMX's open types.</p> <p>So I suggest using only mentioned types for configuration for now.</p> <p>Thanx for the quick response and clear clarification. I will adapt yangs according to mentioned limitations.</p> <p>Regards<br/> Milo</p> Development External issue ID 1410 External issue URL Rank 0|i02lo7: