Date 1 - 3 of 3
Reg: Dynamic registration of Yang Models #opendaylight
|1 - 3 of 3|
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.
To update the schema context that is created as part of the RESTCONF module startup the RESTCONF module library code was modified to add a method to update the schema context and this method was invoked from the flow that introduces new models into the system.
This resolved the initial problem of finding the module in the schema context but the write operation failed later on because the write transaction objects use a In memory data tree snapshot which has the initial schema context encapsulated within it and this snapshot is read-only and initialized as part of the shard creation and therefore cannot be updated directly. Need to find a way to if possible to re-create/update it.
We are not able to find out a way to update the schema context at the global level so that it is reflected in all places where it is used.
We also want to understand how to create an instance of a container within a model that augments a container from another model. it has to be noted that this container is not
explicitly defined as part of the model being augmented.
Appreciate any assistance that will help us to resolve the above issues
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 whichRight, 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.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 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.
|1 - 3 of 3|