18:01:10 #startmeeting tws 18:01:10 Meeting started Mon Jan 30 18:01:10 2017 UTC. The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html. 18:01:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:10 The meeting name has been set to 'tws' 18:01:12 #topic agenda bashing 18:01:18 #chair phrobb 18:01:18 Current chairs: colindixon phrobb 18:01:27 #chair CaseyODL 18:01:27 Current chairs: CaseyODL colindixon phrobb 18:02:01 #link https://bugs.opendaylight.org/show_bug.cgi?id=7522 the bug we'll talk about today 18:02:06 #link Ability to dynamically adding yang schema to MD-SAL global schema context 18:02:13 #info Would like the ability to load YANG models w/o having to load an OSGi bundle to do it 18:02:25 #link https://meetings.opendaylight.org/opendaylight-meeting/2017/kernel_projects/ See 1/24/2017 meeting notes from the Kernel Projects Call for more details 18:05:38 #topic Avi Chapnick presenting 18:05:41 #info slides will follow 18:06:12 #info 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 18:06:25 #info the use case is a VNF configuration manager 18:09:10 #info 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 18:26:24 FYI: regarding the caching mount point: https://github.com/marosmars/caching-mountpoint 18:26:43 Good starting point in Maros's repo 18:26:57 #Info 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 18:28:05 #Info 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 18:28:27 #link https://tools.ietf.org/html/draft-clemm-netmod-mount-05 this is an IETF draft talking about that 18:28:44 #link https://github.com/marosmars/caching-mountpoint some code from Maros (thanks to adetalhouet for the link) 18:32:23 #info 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 18:32:52 so how about having one "mount point" per VNF schema. So we can create instance of it true its associated mount point. 18:33:24 s/true/through 18:36:07 adetalhouet: please feel free to chime in in audio 18:36:49 #info 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 18:38:39 #info 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 18:39:00 #info 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 18:40:40 #Info 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 18:43:06 #Info it sounds like we need to start with the code path for loading modles from jars/OSGi bundles 18:43:44 #Info the pointer into this code path is on the last slide being presented, GlobalBundleScanningSchemaServiceImpl is the relevant class 18:44:07 #Info Avi says there is a loadModule() function on the interface that implements, but it's not implemented yet 18:47:42 #info 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 18:50:15 #info 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) 18:50:21 #info if you then write it back, it might result in destroying augmentations that were already there 18:52:40 #info 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? 18:53:00 #Info rovarga says no becuase the binding class for both augmentations are actually known to the MD-SAL so it can deal with it 18:53:38 #info if we dynamically load it, no binding classes will exist anywhere, and that causes problems 18:54:14 #info 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 18:58:36 #Info 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 18:59:22 good guess :) 18:59:26 hehe 19:01:07 #Info 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 19:02:16 #action colindixon to queue up TWS topics on OpenECOMP and multi-binding issues 19:02:32 #endmeeting