Hello All,

We are building a product in order to provision network devices for which we are using lighty.io as the core framework. We have a few YANG models which serve as the core models and these models get registered with lighty as part of the lighty initialization. 

We also expose few RPC API s that enable writing of data into the MDSAL operational data store corresponding to the above models.
There is a requirement to support introduction of new YANG models into the system and as part of the process, these models need to be
stored into the MDSAL data tree and also dynamically registered with lighty.  Once these models are registered  the expectation is to be able
to write data into the MDSAL data tree for these models.

Currently, we have run into an issue where the dynamic registration of new YANG models is not working as expected and write is not happening
into MDSAL since MDSAL cannot recognize these models .Analysis of the lighty framework code revealed that upfront the lighty framework builds the schema context with the initial set of YANG models that are packaged with the application. This initial schema context is passed down to the RESTCONF module and assigned to some of the objects that are used
during write/read operations to/from MDSAL.
Any new model that gets introduced into the system post startup needs to go into the schema context.
The issue that we are facing is that lighty.io does not offer any API that facilitates addition of new models into the existing schema context and the schema 
context needs to be rebuilt and updated wherever required.

On 20/10/2021 17:00, ravics78@... wrote:

Hello All,

Hello Ravi,

We are building a domain manager product in order to provision network devices in the PON and DOCSIS domains for which
we are using lighty.io as the core framework. We have quite a few YANG models which serve as the core models and these
models get registered with lighty as part of the lighty initialization.

Right, in either case of ODL or lighty.io, there is a set of pre-packaged models. Packaging for both also has Java Binding classes generated.

We also expose few RPC API s that enable writing of data into the MDSAL operational data store corresponding to the above models.
There is a requirement to support introduction of new YANG models into the system and as part of the process, these models need to be
stored into the MDSAL data tree and also dynamically registered with lighty.  Once these models are registered  the expectation is to be able
to write data into the MDSAL data tree for these models.
Currently, we have run into an issue where the dynamic registration of new YANG models is not working as expected and write is not happening
into MDSAL since MDSAL cannot recognize these models .Analysis of the lighty framework code revealed that upfront the lighty framework builds the schema context with the initial set of YANG models that are packaged with the application. This initial schema context is passed down to the RESTCONF module and assigned to some of the objects that are used
during write/read operations to/from MDSAL.
Any new model that gets introduced into the system post startup needs to go into the schema context.
The issue that we are facing is that lighty.io does not offer any API that facilitates addition of new models into the existing schema context and the schema
context needs to be rebuilt and updated wherever required.

Right, and this is boils down to default packaging and use-cases required. OpenDaylight components allow for this amount of flexibility, but not with the constraints you seem to be implying.

This is a use-case trade-off, which has essentially three competing requirements:

1. static component and model wiring (lighty)
2. access through binding APIs (default assumption)
3. runtime introduction of models (mechanism is critical)

In this model you can pick any two and there is a way to wire the components to do the right thing.

You are further constraining 3) by only talking about YANG models themselves. That automatically implies you are willing to forgo 2). Is that correct?

Thanks,
Robert

Hi Robert,

Thanks for your reply.

The requirement that we have is to be able to introduce new models into the system at run time and dynamically registering the models
without having to depend on the bindings. But it looks like the framework itself has some limitations on handling this kind of a scenario.
If the models are included as part of the application and loaded upon startup then it is all green.

Thanks,

Ravishankar