Add YANG model to Device automatically from a YANG library file

[gusmb]

As an idea, instead of adding YANG modules manually to a device and assume that the are in the YANG path, it would be nice to drive everything from the YANG library (https://www.rfc-editor.org/rfc/rfc8525). The library JSON file contains the definition of the YANG model (list of modules and their dependencies). Each module can also contain a "location" field pointing to a remote location where to download the module from. Modules that are not present locally would be downloaded first from their remote location to a local folder in the YANG path. This would avoid maintaining a copy of standard modules locally and would allow to centralize modules with shared data types in a separate repo.

[dhubler]

Sounds very interesting! Yes, today a device has a copy of every yang file and the RESTCONF server that hosts the device automatically adds the YANG library module (RFC8525) so clients can download a copy of each YANG module from the device if clients do not already have a copy. Are you suggesting that devices don't even maintain a copy of the YANG files themselves? Considering devices kinda needed the YANG files when bundling the code support for the implementations, this seemed to reasonable responsibility. I don't work with a lot of industry standard YANG files besides the YANG library one and a few others so I might not have a good understanding of the use case.

[gusmb]

It makes a lot of sense to maintain local copies of all YANG modules on end devices. The use case I have in mind is for generic high-level service models (self-developed) written in YANG, modelling data that is meant to be used by CI/CD pipelines as SoT to build device configurations. In such a use case, all I need is a configuration datastore (or various datastores) where to host the SoT data, and a Restconf API to interact with the data from northbound orchestration bots. So the App wouldn´t do anything (initially) other than reflecting the YANG schema, and exposing it through Restconf, providing one or more datastores to host the data.

Let's say I have a YANG library file as follows:

File: yang-library-example-service.json

{
  "ietf-yang-library:yang-library": {
    "module-set":  [
      "name": "service-module-set",
      "module": [
        {
          "name": "example-service",
          "namespace": "http://example.com/example-service",
          "revision": "",
          "location": "http://example.com/yang/example-service.yang",
        },
        {
          "name": "ietf-yang-metadata",
          "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-metadata",
          "revision": "2016-08-05",
          "location": "https://github.com/YangModels/yang/blob/main/standard/ietf/RFC/ietf-yang-metadata%402016-08-05.yang"
        },
        {
          "name": "ietf-origin",
          "namespace": "urn:ietf:params:xml:ns:yang:ietf-origin",
          "revision": "2018-02-14",
          "location": "https://github.com/YangModels/yang/blob/main/standard/ietf/RFC/ietf-origin%402018-02-14.yang"
        }
      ],
      "import-only-module": [
        {
          "name": "example-service-types",
          "namespace": "http://example.com/example-service-types",
          "revision": "",
          "location": "http://example.com/yang/example-service-types.yang"
        }
      ]
    ]
  }
}

Then instead of manually registering the YANG modules, I would pass the YANG library JSON definition and the app would register them accordingly, expecting to find the modules somewhere in the YANG path. Optionally, a flag could be used to instruct the app to download modules from their remote location (corresponding GIT repos) on first initialization.

[dhubler]

Sounds like a rather specific use case, but one that should be very do-able w/FreeCONF. Device should let you register modules dynamically and with any implementation you want for any module.

…

On Wed, Jun 28, 2023 at 3:51 PM Gustavo Martinez Barbero < ***@***.***> wrote: It makes a lot of sense to maintain local copies of all YANG modules on end devices. The use case I have in mind is for generic high-level service models (self-developed) written in YANG, modelling data that is meant to be used by CI/CD pipelines as SoT to build device configurations. In such a use case, all I need is a configuration datastore (or various datastores) where to host the SoT data, and a Restconf API to interact with the data from northbound orchestration bots. So the App wouldn´t do anything (initially) other than reflecting the YANG schema, and exposing it through Restconf, providing one or more datastores to host the data. Let's say I have a YANG library file as follows: File: yang-library-example-service.json { "ietf-yang-library:yang-library": { "module-set": [ "name": "service-module-set", "module": [ { "name": "example-service", "namespace": "http://example.com/example-service", "revision": "", "location": "http://example.com/yang/example-service.yang" ], "conformance-type": "implement" }, { "name": "example-service-types", "namespace": "http://example.com/example-service-types", "revision": "", "conformance-type": "import", "location": "http://example.com/yang/example-service-types.yang" }, { "name": "ietf-yang-metadata", "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-metadata", "revision": "2016-08-05", "conformance-type": "implement", "location": "https://github.com/YangModels/yang/blob/main/standard/ietf/RFC/ietf-yang-metadata%402016-08-05.yang" }, { "name": "ietf-origin", "namespace": "urn:ietf:params:xml:ns:yang:ietf-origin", "revision": "2018-02-14", "conformance-type": "implement", "location": "https://github.com/YangModels/yang/blob/main/standard/ietf/RFC/ietf-origin%402018-02-14.yang" } ] ] } } Then instead of manually registering the YANG modules, I would pass the YANG library JSON definition and the app would register them accordingly, expecting to find the modules somewhere in the YANG path. Optionally, a flag could be used to instruct the app to download modules from their remote location (corresponding GIT repos) on first initialization. — Reply to this email directly, view it on GitHub <#38 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACA7WV2XVETIXP3B5UBKLXNSDKVANCNFSM6AAAAAAZXC7SZ4> . You are receiving this because you commented.Message ID: ***@***.***>