16:01:27 <colindixon> #startmeeting MD-SAL interest call
16:01:27 <odl_meetbot> Meeting started Tue Sep  8 16:01:27 2015 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:01:27 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:27 <odl_meetbot> The meeting name has been set to 'md_sal_interest_call'
16:01:30 <colindixon> #topic agenda bashing
16:02:19 <colindixon> #chair rovarga_
16:02:19 <odl_meetbot> Current chairs: colindixon rovarga_
16:02:23 <colindixon> #chair phrobb-
16:02:23 <odl_meetbot> Current chairs: colindixon phrobb- rovarga_
16:03:17 <colindixon> #info topic today is to cover the migration from inventory to topology and then possibly to a new topology model
16:04:30 <colindixon> #link https://github.com/opendaylight/controller/blob/master/opendaylight/model/model-inventory/src/main/yang/opendaylight-inventory.yang inventory model
16:05:24 <colindixon> #link https://github.com/opendaylight/yangtools/tree/master/model/ietf/ietf-topology/src/main/yang the “current” topology models
16:05:44 <colindixon> #link https://git.opendaylight.org/gerrit/#/c/23735/ the change that would add the “new” topology model
16:07:59 <colindixon> #topic background
16:09:17 <colindixon> #info ttkacik says that since the beginning of OpenDaylight we have had two models: inventory and topology, many people used the inventory model becasue it more closesly matched the AD-SAL (among other things)
16:11:48 <colindixon> #info over time we’ve found that the topology model is more interesting, rich and useful, e.g., we have multiple topologies which can be (but don’t have to be) overlays or underlays of each othe
16:12:42 <colindixon> #info it also turns out that the network topology model is deprecated and the new model is substantively differnet with two parts
16:12:49 <colindixon> #info look above for links
16:13:16 <colindixon> #undo
16:13:16 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1ce0cd0>
16:13:20 <colindixon> #udno
16:13:23 <colindixon> #undo
16:13:23 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1ce03d0>
16:13:35 <colindixon> #info it also turns out that the network topology model is expired (the draft which proposed it) and the new model is substantively differnet with two parts
16:13:47 <colindixon> #info look above for links
16:14:42 <colindixon> #info the new one has two parts: (a) the network model which is close to our inventory and (b) the topology model which adds in links and terminate points
16:15:21 <colindixon> #info vishnoianil_ says so right now we have two models for topology: one which is expired and another which is not yet approved, should we worry about that?
16:15:34 <colindixon> #info rovarga_ and ttkacik say that even RESTCONF isn’t standardized yet
16:15:46 <colindixon> #topic planning for the migration
16:16:17 <colindixon> #info vishnoianil_ asks where they should migrate in the openflow plugin: should they move to the expired draft or the new I2RS-based draft?
16:16:56 <colindixon> #info rovarga_ says his take is that because the expired draft is used nearly everywhere in ODL, it might make the most sense to move to the expired draft first
16:17:23 <colindixon> #info in part this is because he thinks the topology processing framework project might be able to help with migration from one topology model to the next
16:17:59 <colindixon> #info abhijitkumbhare asks if it would be easier for everyone to migrate to the new model
16:18:34 <colindixon> #info rovarga_ says that just has the risk that moving *everyone* (inventory and topology) users would be a bigger undertaking than just moving the inventory folks
16:21:14 <colindixon> #info colindixon notes that since we will have to support the deprecated models, if we moved through the expired draft model, it would (potentially) incerase the number of compatibility translators we’d need
16:23:13 <colindixon> #info Michal Polkorab says that the OpenFlow plugin already have some code which helps to merge the data from inventory into the topology as well (or vice versa)
16:23:49 <colindixon> #info rovarga_ and ttkacik note that this is easy if you use groupings since you just augment the models to inject (the same) groupings in both places
16:24:12 <colindixon> #info it sounds like there’s some tricks that are being done for topology processing frame work to semi-automate the translation
16:25:51 <colindixon> #info vishnoianil_ says that he worries a little bit about the appearance of ODL continously deprecating things, so if we know where we want to be, we might as well corectly signal how we’re going to move
16:28:44 <colindixon> #info colindixon says if we’re sure that we’re going to deprecate the expired draft, maybe we should do it *now* so that we can best signal to people what we’re planning to do
16:29:18 <colindixon> #info rovarga_ says he mostly agrees, but likes to avoid deprecating things until there is an alternative with a migration plan (which we don’t really have right now)
16:29:41 <colindixon> #info abhijitkumbhare asks if we have a comparison of the 2-3 options we’re talking about
16:29:53 <colindixon> #info rovarga_ says we don’t really have one right now, and he’s not sure we have the cycles to do it
16:31:23 <colindixon> #info colindixon previously noted that there are two orthogonal questions here: (a) what APIs we mark as deprecated and eventaully phase out and when and (b) what models we internally use as backing implementations
16:31:50 <colindixon> #info this is becuase we have to make translators for backward compatibility anyway
16:33:28 <colindixon> #topic internal vs. external consumers of our APIs
16:33:54 <colindixon> #info colindixon asks if we have a list of who’s using the topology and inventory APIs (at least internal projects)
16:34:53 <colindixon> #info moiz asks what about external conusmers
16:37:31 <colindixon> #info colindixon notes that we have committed to provide the same APIs for at least a whole release as deprecated before we can remove it (and even then, we don’t have to remove it immediately)
16:37:46 <colindixon> #topic developer effort of migrating
16:37:57 <colindixon> #info people ask how long migration would take
16:38:26 <colindixon> #info colindixon says that his guess would be about a week of effort to inject the same augmentations into topology as well as inventory and then change which ones you populate
16:38:35 <colindixon> #info vishnoianil_ also notes that migration integration tests will be some work
16:39:00 <colindixon> #info there’s also a note about that assumes using the topology processing framework for automated populating of multiple models with the given augmentations
16:40:19 <colindixon> #action colindixon will produe a list of what projects are using these models so that we can use that inform our decisions
16:40:35 <colindixon> #action colindixon to add this as (at least a 5 minute) topic on the TWS next week
16:44:38 <colindixon> #topic questions going forward
16:44:46 <colindixon> #info we WILL deprecate inventory in Be
16:44:57 <hideyuki> What's the plan of the migration to use MD-SAL of MD-SAL project instead of one of the Controller project?
16:45:03 <hideyuki> By when do projects must migrate to use MD-SAL project?
16:45:50 <colindixon> #info it’s unclear if we we will depcrate the expired draftt model for network-topology
16:46:14 <colindixon> #info in theory we coudl deprecate it as late as M4, but that might be mean
16:47:16 <colindixon> #info the second set of questions is how our implementation works
16:48:42 <colindixon> #info it sounds like plan A is for the topology processing framework to provide tooling to make it easy to provide translators that copy data between multiple such models
16:49:20 <colindixon> #info this would make the choice of what model to base your implementation on somewhat a project-by-project issue
16:49:47 <colindixon> #info rovarga_ notes that there will be performance implications if a cosumer reads from/writes to a different model than an implemenation is based in
16:50:42 <colindixon> #info each project would still need to decide which model to base themselves on, when to move, and how to communicate the move with any implications to their consumers
16:51:38 <colindixon> #topic openflow plugin (like the most affected proejct here)
16:52:12 <colindixon> #Info colindixon asks michal and abhijitkumbhare what they’re leaning towards
16:52:21 <colindixon> #info abhijitkumbhare says they’ll need to talk about it internally
16:53:34 <colindixon> #info abhijitkumbhare says there is a meeting tomorrow at 8a pacific for the OpenFlow plugin and they’ll plan to discuss this ther
16:53:37 <colindixon> #undo
16:53:37 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x189f250>
16:53:39 <colindixon> #info abhijitkumbhare says there is a meeting tomorrow at 8a pacific for the OpenFlow plugin and they’ll plan to discuss this there
16:54:55 <colindixon> #action abhijitkumbhare to email odl-casey to set up a one-off webex for 8a pacific tomorrow
16:56:13 <colindixon> #topic IETF standardizations
16:56:38 <colindixon> #info vishnoianil_ asks how long does it take for a IETF draft to become official
16:56:49 <colindixon> #info rovarga_ and ttkacik say this part has been going on for 3 years
16:57:16 <colindixon> #info rovarga_ says the stateful PCEP took 5 years
16:59:40 <colindixon> #info colindixon notes that we have think about how and when we adopt changest from upstream organizations and have some ideas why we do what we do
17:00:33 <colindixon> #endmeeting