[release] [OpenDaylight TSC] ODL yang models


Nidhi Adhvaryu <nidhi.adhvaryu@...>
 

Hi Luis,

I have incorporated few failures identified in yang model for genius.
I have raised a patch here, https://git.opendaylight.org/gerrit/#/c/genius/+/85534/

Is there any jira raised for this activity?

Thanks,
Nidhi Adhvaryu

-----Original Message-----
From: release@... <release@...> On Behalf Of Robert Varga via Lists.Opendaylight.Org
Sent: Wednesday, October 23, 2019 2:41 PM
To: Luis Gomez <ecelgp@...>; Release <release@...>; tsc <tsc@...>
Cc: release@...
Subject: Re: [release] [OpenDaylight TSC] ODL yang models

On 22/10/2019 21:08, Luis Gomez wrote:
Hi everyone,

You may know already, we have an ODL intern, Rohan Julka, working on
yang model pushing to Yang github (https://protect2.fireeye.com/v1/url?k=ee7a31d0-b2ae346f-ee7a714b-868f633dbf25-abae512c859ad01f&q=1&e=93aaea4f-322c-4e0b-9a6f-56add005a851&u=https%3A%2F%2Fgithub.com%2FYangModels%2Fyang).

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:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/distributio
n-merge-managed-magnesium/657/opendaylight-models/

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?
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
 

No that I know, but I should probably ask the intern to do so, so at least we have a per-project track.

On Nov 6, 2019, at 4:25 AM, Nidhi Adhvaryu <nidhi.adhvaryu@...> wrote:

Hi Luis,

I have incorporated few failures identified in yang model for genius.
I have raised a patch here, https://git.opendaylight.org/gerrit/#/c/genius/+/85534/

Is there any jira raised for this activity?

Thanks,
Nidhi Adhvaryu


-----Original Message-----
From: release@... <release@...> On Behalf Of Robert Varga via Lists.Opendaylight.Org
Sent: Wednesday, October 23, 2019 2:41 PM
To: Luis Gomez <ecelgp@...>; Release <release@...>; tsc <tsc@...>
Cc: release@...
Subject: Re: [release] [OpenDaylight TSC] ODL yang models

On 22/10/2019 21:08, Luis Gomez wrote:
Hi everyone,

You may know already, we have an ODL intern, Rohan Julka, working on
yang model pushing to Yang github (https://protect2.fireeye.com/v1/url?k=ee7a31d0-b2ae346f-ee7a714b-868f633dbf25-abae512c859ad01f&q=1&e=93aaea4f-322c-4e0b-9a6f-56add005a851&u=https%3A%2F%2Fgithub.com%2FYangModels%2Fyang).

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:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/distributio
n-merge-managed-magnesium/657/opendaylight-models/

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?
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