Operating System: All
Platform: All

this needs support from Yangtools and further dev discussion

based on information from yangtools-dev team, there won't be any changes/implementation done in Yangtools code, so one has to support this in client application. You might want to open discussion on mailing list. Closing bug as WON'T FIX

Martin, is this being closed because the yangtools developers feel like it's fundamentally a bad idea or merely because the cycles to fix it don't exist at the moment.

If it's the latter, it's probably better to not mark it as RESOLVED WONTFIX.

It seems like we already do this when loading OSGi bundles, so we really ought to be able to trigger the same code path dynamically. Is my thinking wrong?

@Avi, based on some back and forth with Brian Freeman, I'm moving this to CONFIRMED and adding it to the Kernel Projects Call for next week here:
https://wiki.opendaylight.org/view/Kernel_Projects_Call#Upcoming_Agenda_Topics

If you could attend that call to figure out if there's any additional information you need before being able to take a swag at fixing it, that would be awesome.

It's Tuesday, January 24th at 9a pacific.

As discussed on the MD-SAL call, the solution here depends on the use case. My understanding is that this is to store SB device configuration in the controller.

While we can populate the global controller SchemaContext with these models, it does have two down sides:
1) not providing uniform access to Binding applications
2) potentially mixing up the data models of the controller and the southbound device

For this reason we have chosen to populate the global context strictly from bundles deployed – with that we do not risk having something in the system for which we do not have bindings. It is an ugly, but effective way of ensuring that.

The second problem is actually worse, because in the generic case the southbound device could be a previous or future version of ODL – at which point we have genuine model version clashes, leading to 'this is weird' kind of bugs.

There are multiple options on how to make this work, for which we need to have a better understanding of what the access requirements are. From the description this feels like it has some overlap with https://tools.ietf.org/html/draft-clemm-netmod-mount-05, but that needs to be confirmed. If that is the case, we definitely have all the tools for the job readily available.

The consensus is to keep this issue open in mdsal, until we have a better understanding of the use case. This will be subject of next week's TWS, after which we will decide what to do with this issue.

Several questions/comments

1. The business requirement is manage VNF/VF configuration in MDSAL application as part of somewhat of a VNFM implementation, these configuration doesn't have to relate directly to the SB device configuration/schema , it might be the SB device will be CLI based and thus no schema to represent its configuration.
the configuration will not necessarily will be network related, it can be VNF specific setting. having said , we are using MDSAL capabilities to create a configuration manager and not to develop a network/DSN application per-se .
I will describe that in the TWS.

2. from what I seen/tried so far , there is option to import a bundle with no generated binding , only with the yang schema file and the schema gets consumed to the global context, with that today ODL expose to the risks described above.

3. regarding uniform access to binding application , If one binding application is reading data which is stored by another binding application , is it still have access to all the generated binding , even if these are part of a different deployed bundle? is MDSAL even allows that?

Our interfaces are organized in a way, which allows a different DOMSchemaService to be implemented as needed. In particular yang-parser-api provides everything needed to establish an EffectiveModelContext.

This requirement does not align up with any use case we currently support and will not be implemented.