#opendaylight-meeting: tws

Meeting started by colindixon at 18:01:10 UTC (full logs).

Meeting summary

  1. agenda bashing (colindixon, 18:01:12)
    1. https://bugs.opendaylight.org/show_bug.cgi?id=7522 the bug we'll talk about today (colindixon, 18:02:01)
    2. Ability to dynamically adding yang schema to MD-SAL global schema context (colindixon, 18:02:06)
    3. Would like the ability to load YANG models w/o having to load an OSGi bundle to do it (colindixon, 18:02:13)
    4. https://meetings.opendaylight.org/opendaylight-meeting/2017/kernel_projects/ See 1/24/2017 meeting notes from the Kernel Projects Call for more details (colindixon, 18:02:25)

  2. Avi Chapnick presenting (colindixon, 18:05:38)
    1. slides will follow (colindixon, 18:05:41)
    2. this is the use case which generated the requirement to be able to dynamically load a YANG modeule into the global schema context of OpenDaylight (colindixon, 18:06:12)
    3. the use case is a VNF configuration manager (colindixon, 18:06:25)
    4. the general idea is that the app wants to host YANG schemas for VNFs and then translate them into underylying protocol whether it's NETCONF, CLI aor Ansible (colindixon, 18:09:10)
    5. colindixon says he thinks the two goals for today are (a) establishing if it makes sense to be able to dynamically load YANG modules into ODL w/o having to load an OSGi model and (b) if so, what's the right place to start (colindixon, 18:26:57)
    6. rovarga talks some about how to do the part which they call "alias mounting", specifically he says that you could use some kind of caching mountpoint (colindixon, 18:28:05)
    7. https://tools.ietf.org/html/draft-clemm-netmod-mount-05 this is an IETF draft talking about that (colindixon, 18:28:27)
    8. https://github.com/marosmars/caching-mountpoint some code from Maros (thanks to adetalhouet for the link) (colindixon, 18:28:44)
    9. moving back to taking about how to actually load modules into OpenDaylight, rovarga says that our current assumption is that a single datastore, e.g., mountpoint, has a single schema context (colindixon, 18:32:23)
    10. colindixon asks why we can't just use the same logic to load models dyanmically w/o jars/OSGi bundles as we do with jars/OSGi bundles (colindixon, 18:36:49)
    11. rovarga says that would be fine until you have possibly conflicting models, colindixon says we could maybe start with the assmption that we won't have any conflicts and solve that if and when we have to (colindixon, 18:38:39)
    12. Avi confirms what colindixon suspects that the models being loaded in this way are under their control, so we don't have to worry about conflicts (colindixon, 18:39:00)
    13. colindixon asks they are planning to reuse types from the SB models in the NB models, if so that might make things harder, for now Avi says that nothing but standard ietf-inet-types and ietf-yang-types (colindixon, 18:40:40)
    14. it sounds like we need to start with the code path for loading modles from jars/OSGi bundles (colindixon, 18:43:06)
    15. the pointer into this code path is on the last slide being presented, GlobalBundleScanningSchemaServiceImpl is the relevant class (colindixon, 18:43:44)
    16. Avi says there is a loadModule() function on the interface that implements, but it's not implemented yet (colindixon, 18:44:07)
    17. rovarga says "yes, and it can't really be implemented" because it would need to have a way to add more than one module at the same time if they depend on each other and a way to fail if cross-module issues happen so that you can roll back to the old context (colindixon, 18:47:42)
    18. another issue is that as it's built today, there aren't binding classes generated on module loading, so if someody read an MD-SAL data item which was augmented by such a dynamically loaded module, wouldn't be readable (and might cause undefined behavior) (colindixon, 18:50:15)
    19. if you then write it back, it might result in destroying augmentations that were already there (colindixon, 18:50:21)
    20. colindixon tries to restate Avi's question: if bundle A has module A that aguments topology nodes and bundle B has module B that also augments topology nodes, then if they both actually instantiate their agumentation do they have the same issue? (colindixon, 18:52:40)
    21. rovarga says no becuase the binding class for both augmentations are actually known to the MD-SAL so it can deal with it (colindixon, 18:53:00)
    22. if we dynamically load it, no binding classes will exist anywhere, and that causes problems (colindixon, 18:53:38)
    23. rovarga says it sounds like it's just a matter of implementing this API and then making sure we either give proper warnings or authorization to keep people from doing it willy nilly (colindixon, 18:54:14)
    24. avi says he'll probably be working on this, he says he'll probably come for more help, colindixon says the best starting place is the kernel projects call on Tuesdays (colindixon, 18:58:36)
    25. rovarga says that this we have models, but not bindings will also matter as we move to binding v2 and have more than one binding (colindixon, 19:01:07)
    26. ACTION: colindixon to queue up TWS topics on OpenECOMP and multi-binding issues (colindixon, 19:02:16)


Meeting ended at 19:02:32 UTC (full logs).

Action items

  1. colindixon to queue up TWS topics on OpenECOMP and multi-binding issues


Action items, by person

  1. colindixon
    1. colindixon to queue up TWS topics on OpenECOMP and multi-binding issues


People present (lines said)

  1. colindixon (37)
  2. adetalhouet (6)
  3. odl_meetbot (5)
  4. CaseyODL (0)
  5. phrobb (0)


Generated by MeetBot 0.1.4.