16:04:31 <yamahata> #startmeeting neutron_northbound
16:04:31 <odl_meetbot> Meeting started Fri Nov 20 16:04:31 2015 UTC.  The chair is yamahata. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:04:31 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:31 <odl_meetbot> The meeting name has been set to 'neutron_northbound'
16:05:30 <yamahata> it seems like we don't have quorum. but I hold a meeting to keep this neutron northbound irc meeting alive given that it has not been held for the past three times.
16:05:38 <john_a_joyce> hello isaku
16:05:38 <yamahata> #topic agenda bashing and roll call
16:05:56 <yamahata> john_a_joyce: hello
16:06:15 <yamahata> #link https://wiki.opendaylight.org/view/NeutronNorthbound:Meetings meeting agenda
16:06:28 <yamahata> today we don't have much items
16:06:34 <yamahata> anything else to discuss?
16:06:44 <rcurran> hi - if it's just john and i then this will be a short meeting (considering we met last night)
16:07:07 <vthapar> I got couple small items.
16:07:32 <yamahata> vthapar: if it's small, let's cover them at openmike part
16:07:45 <yamahata> #topic Announcements
16:07:45 <vthapar> yamahata: +1
16:08:06 <yamahata> M4 is cut. But we haven't reported our one.
16:08:38 <yamahata> #action yamahata report M4 as soon as possible
16:08:48 <yamahata> it's already one week late
16:09:43 <yamahata> anyone else to announce?
16:11:07 <yamahata> next topic
16:11:15 <yamahata> #topic recap from openstack summit
16:11:47 <yamahata> At the summit we had meetings. As summary here is a etherpad page https://etherpad.openstack.org/p/neutron-northbound
16:12:02 <yamahata> #link https://etherpad.openstack.org/p/neutron-northbound meeting minutes at the tokyo summit
16:13:17 <yamahata> #topic action items from last meeting
16:13:37 <yamahata> patch review https://git.opendaylight.org/gerrit/#/c/24598/
16:13:46 <yamahata> I gave it a review yesterday
16:14:13 <yamahata> #topic bug
16:14:42 <yamahata> #link https://bugs.launchpad.net/networking-odl/+bug/1504671
16:15:13 <yamahata> I haven't a chance to look into it yet. It's not resolved yet. Will keep to track it
16:15:25 <yamahata> #topic ML2 ODL driver rewrite
16:16:16 <yamahata> Now people are back from the tokyo summit and starting to push patches/review.
16:16:42 <yamahata> Do we have specific issues for specific patches?
16:17:17 * yamahata waiting...
16:17:26 <john_a_joyce> no issues from me
16:17:51 <yamahata> okay let's move on
16:17:58 <yamahata> #topic open mike
16:17:59 <john_a_joyce> on the refactor patch we need to make the changes for the database locking as discussed in the summit
16:18:14 <john_a_joyce> so that will be a week or so before a new patch is submitted
16:18:22 <yamahata> #undo
16:18:22 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x251cd90>
16:19:12 <yamahata> #topic open mike
16:19:26 <yamahata> vthapar: your turn
16:19:44 <vthapar> first up, https://review.openstack.org/#/c/231321/
16:20:24 <vthapar> bgpvpn driver in networking-odl.
16:20:40 <vthapar> anything else needed in there?
16:21:36 <yamahata> Basically it looks good.
16:21:58 <yamahata> What's the conclusion for a place to store the driver?
16:22:05 <yamahata> networking-odl or networking-bgpvpn?
16:22:33 <vthapar> networking-odl is the preferred long term, but while bgpvpn api evolves will keep a copy in bgpvpn and use it.
16:22:57 <yamahata> If it would be a big issue for networking-bgpvpn, let's resolve it
16:23:05 <vthapar> so, if this n-odl gets merged, subsequent changes/experimentation will happen in bgpvpn.
16:23:41 <yamahata> Agree with you for long term.
16:23:51 <vthapar> their main concerns were on how easy or diffuclt it will be to port this driver to Liberty and potentially kilo.
16:25:51 <vthapar> cool,Matheiu added link to n-bgpvpn driver too, in case anyone wants to review.
16:26:16 <vthapar> I'll be adding tests etc. mostly there. n-odl I'll revisit once the resync/journaling infra is in place.
16:26:29 <vthapar> am expecting it will be available to bgpvpn driver also.
16:27:33 <vthapar> good?
16:27:37 <yamahata> #link https://review.openstack.org/#/c/231321/ bgpvpn
16:28:51 <yamahata> It wouldn't be difficult to port the driver to Liberty or Kilo
16:29:39 <vthapar> I think concern on bgpvpn side was more about syncing releases and maybe they felt more comfortable if it were in bgpvpn.
16:29:52 <yamahata> resync/journaling would be tricky. Since it's on-going issue, it's another topic
16:29:57 <vthapar> coz as for api changes, I could easily make changes in n-odl too.
16:30:22 <yamahata> I see. Do you see major API changes for Mitaka?
16:30:22 <vthapar> agree, not looking for it [journaling/resync] in short term but as long term goal
16:30:41 <vthapar> from discussions looks like yes.
16:31:49 <yamahata> In that case, it might be an option to store the driver in n-bgpvpn for mitaka, and then move it to n-odl at N cycle.
16:31:50 <vthapar> the current urgency is because they want to cut liberty release asap.
16:32:30 <vthapar> so you mean not have it in n-odl till it stablizes?
16:32:45 <yamahata> Given n-odl is already cut for Liberty, it makes sense to put the driver in n-bgpvpn for Liberty
16:33:27 <vthapar> agree. saves the effort of backport. but what about Mitaka?
16:33:55 <yamahata> yes until stabilization, keep it in n-bgpvpn. and then move it to n-odl at some point
16:34:02 <vthapar> some of changes will require additions to NeutronNorthbound eventually
16:34:36 <vthapar> ok. sounds good.
16:35:01 <vthapar> so abandon the one in n-odl? or let it merge for now?
16:35:33 <yamahata> How about putting the driver in n-bgpvpn as experimental. at least until Mitaka-2
16:35:51 <yamahata> At that time, if we feel bgpvpn api is stabilized, we can move it to n-odl.
16:36:21 <yamahata> abandon the one in n-odl for now and put it in n-bgpvpn.
16:36:25 <vthapar> good enough for me, though it means you will be occasionally pulled in to review changes :)
16:36:26 <yamahata> Does it make sense?
16:36:55 <yamahata> you need to ping me time to time for review
16:38:03 <vthapar> okay.
16:38:12 <yamahata> If possible, I'd like to hear opinions from distro or OPNFV
16:38:22 <vthapar> one thing though, this will mean some changes in ODL Neutron from time to time.
16:39:36 <yamahata> What kind of chages do you expect? except driver itself.
16:39:55 <yamahata> Do you need some changes to neutron-odl?
16:39:58 <vthapar> changes in data model/api resulting in changes to yang...
16:40:20 <yamahata> Oh model/api itself.
16:40:25 <vthapar> adding more attributes, sub-objects etc.
16:40:26 <vthapar> yep
16:41:14 <yamahata> Hmm, in that case we should wait api stabilization for each cycle
16:42:08 <vthapar> the one that is going in liberty will work with our current Be one. am handling differences in Driver. changes will come in post Be I believe.
16:44:19 <yamahata> Sounds plausible and it would be manageable.
16:44:55 <yamahata> So you are planning (major) model/api changes post-Be
16:45:38 <vthapar> from discussions yes. since they want to cut liberty, had to postpone certain use cases for now which will come once liberty is done.
16:46:49 <yamahata> okay, sounds good
16:47:04 <vthapar> can I move to next on my list? :)
16:47:13 <yamahata> yeah
16:47:42 <vthapar> I'd like option in our devstack to skip waiting for bridge...
16:47:56 <vthapar> wanted to know if sounds like good idea?
16:48:14 <vthapar> I use it for testing bgpvpn driver where I only run NeutronNorthbound, no OVSDB.
16:48:48 <vthapar> something like ODL_WAIT_FOR_BRIDGE that defaults to true
16:50:19 <vthapar> sounds useful?
16:51:15 <yamahata> maybe. can you upload the patch?
16:51:46 <vthapar> will do, should there be a bug for it?
16:52:30 <yamahata> Yes
16:52:47 <vthapar> will do that.
16:53:14 <vthapar> finally, I missed it earlier during meeting, but Ravi has pushed another patchset addressing your comments in https://git.opendaylight.org/gerrit/24598
16:54:22 <yamahata> got it
16:54:29 <yamahata> #link https://git.opendaylight.org/gerrit/24598 new patches uploaded
16:55:01 <yamahata> BTW, is it possible for bgpvpn and l2gw to use restconf directly?
16:55:21 <yamahata> In that case, we don't have to include northbound code and type conversion code.
16:55:45 <yamahata> it's trade off between api compatibility, though.
16:55:46 <vthapar> that was the question I had at ODL Summit :) why can't drivers use restconf directly.
16:55:58 <yamahata> model changes are directly visible through restconf.
16:56:03 <vthapar> do we plan to eventually move towards that design?
16:56:34 <yamahata> We need to give it consideration for backward api compatibility.
16:56:54 <yamahata> but bgpvpn and l2gw don't have the compatibility issue.
16:57:23 <yamahata> If bgpvpn and l2gw are fine with restconf, I prefer restconf.
16:57:26 <vthapar> hmm... I can work on that... what about issues like - in tenant id etc.
16:58:09 <vthapar> what I'll do is let driver in bgpvpn use way it is, one in n-odl I'll modify to use restconf.
16:58:25 <vthapar> this will help separate out experimentations to respective projects.
16:59:12 <vthapar> sounds good?
16:59:20 <yamahata> yes. makes sense.
16:59:24 <yamahata> 1 minutes left.
16:59:42 <yamahata> any other topics?
17:00:34 * vthapar is done
17:01:08 <yamahata> okay thanks
17:01:13 <yamahata> #topic cookies
17:01:22 <yamahata> #endmeeting