Date
1 - 4 of 4
ODL yang models
|
Luis Gomez
Hi everyone,
You may know already, we have an ODL intern, Rohan Julka, working on yang model pushing to Yang github (https://github.com/YangModels/yang). As part of this exercise, we added a test in the distribution merge job to collect and verify ODL generated yang models using pyang, see the results here: The test shows we have issues in many models (see error file under each project). Some of them like "import" not used, are easy to fix and have no impact, but other may require further analysis and the fix may impact the API. So how do we want to go about this? should we open bugs to every project to fix this? any other idea to get the models repaired? BR/Luis |
|
|
|
Robert Varga
On 22/10/2019 21:08, Luis Gomez wrote:
Hi everyone,Well, we need attribution to where the model is packaged -- the current approach of matching namespace is nice (in that it points out wrong namespaces), but really those 'external' models need to be charged to the project packaging them (most of which is mdsal, as designed). As for the individual failures ... yeah, they need to be classified and analyzed, as for example we are more liberal around keyless lists in config (because they are not a problem for our internal workings). Regards, Robert |
|
|
|
Luis Gomez
For this check we are using the same script that will collect and push ODL modules to Yang github. Because of this, all external (non ODL models) are organized in a separate folder. But let me ask: what is the value-add of having the external modules in the corresponding projects? If there is some, we can have custom script for just verifying the models in CI.
|
|
|
|
Luis Gomez
BTW, I forgot to mention this effort of checking yang models per-project is also available for Self-Managed projects (use merge-full vs merge-managed in the job name):
toggle quoted message
Show quoted text
BR/Luis
|
|
|