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