16:01:33 <yamahata> #startmeeting neutron_northbound
16:01:33 <odl_meetbot> Meeting started Fri Feb 19 16:01:33 2016 UTC.  The chair is yamahata. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:01:33 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:33 <odl_meetbot> The meeting name has been set to 'neutron_northbound'
16:01:42 <yamahata> #topic agenda bashing and roll call
16:01:49 <yamahata> #info yamahata
16:02:08 <yamahata> #link https://wiki.opendaylight.org/view/NeutronNorthbound:Meetings#Agenda_for_Next_Meeting_.28Feb.2F19.2C_2016.29 agenda
16:02:27 <yamahata> today I don't special topic except usual one.
16:02:32 <yamahata> any topics?
16:03:37 <yamahata> seems nothing else.
16:03:39 <yamahata> #topic Announcements
16:03:52 <yamahata> ODL Beryllium was released.
16:04:01 <yamahata> Thank you for your help
16:04:20 <yamahata> The official announcement would be on monday, though.
16:05:05 <yamahata> So I uploaded couple of patches for networking-odl for beryllium and boron
16:05:22 <yamahata> any other announcement?
16:06:19 <yamahata> #topic action items from last meeting
16:06:34 <yamahata> yamahata reviewed V2 driver patches.
16:07:06 <yamahata> But he is still catching up patch review on networking-odl. plan to catch them up today.
16:07:23 <yamahata> asomya: uploaded the patch. thanks!
16:07:36 <rcurran> thanks. we are backed up w/ L3 + required bugfixes
16:07:44 <rcurran> that are all in the queue
16:07:50 <yamahata> #topic Open Patch sets needing review/merging
16:08:08 <yamahata> I'd like to raise patch review
16:08:15 <rcurran> yamahata, are there any other cores that we need to review these patches?
16:08:16 <yamahata> #link https://review.openstack.org/#/c/279843/
16:08:32 <yamahata> rcurran: Effectively no one else.
16:08:50 <rcurran> yeah, not seeing much traffic these days from other networking-odl cores
16:09:02 <asomya> yamahata: We posted an alternate fix for the test breakage https://bugs.launchpad.net/networking-odl/+bug/1545827
16:09:03 <yamahata> So we need new _active_ cores.
16:09:51 <asomya> https://review.openstack.org/#/c/280374/ https://review.openstack.org/#/c/281308/
16:10:20 <yamahata> asomya: thanks. The bug is a blocker. So let's merge your patch to unblock it.
16:10:39 <yamahata> After the real fix goes into neutron, let's revert it.
16:10:48 <yamahata> asomya: does it sound reasonable?
16:11:11 <asomya> yamahata: sounds good, Federico has a follow up patchto mine that improves it a bit
16:11:48 <rcurran> so the real fix is coming from neutron/ ?
16:12:06 <yamahata> rcurran: yes https://review.openstack.org/#/c/279843/
16:12:41 <yamahata> The real cause is that the test had wrong assumption. I rewrite the test
16:12:46 <rcurran> ok, so any reason to add federico's follow-on to arvind's? seems like we'll eventually back out arvinds
16:12:56 <yamahata> it would take a while for review, though.
16:13:11 <asomya> rcurran: Don't know when it'll be accepted to Neutron :)
16:13:44 <yamahata> #action yamahata review https://review.openstack.org/#/c/280374/ and unblock networking-odl asap
16:14:00 <yamahata> #action everyone review https://review.openstack.org/#/c/279843/
16:15:02 <yamahata> I also raise another bug
16:15:08 <yamahata> https://review.openstack.org/#/c/281621/
16:15:28 <yamahata> #link https://bugs.launchpad.net/networking-odl/+bug/1546848 Java moxy bug
16:15:45 <yamahata> #link https://review.openstack.org/#/c/281621/ work around patch of moxy bug
16:16:27 <yamahata> it isn't urgent, though.
16:16:47 <yamahata> any other patches or bugs?
16:17:35 <rcurran> you'll want to look at yalie's patch - https://review.openstack.org/#/c/281144/
16:17:53 <rcurran> introduces new callins for SG events
16:18:11 <yamahata> rcurran: difinitively
16:18:19 <rcurran> i think this should be a patchset of just the new SG registry calls and UTs
16:18:20 <yamahata> #info https://review.openstack.org/#/c/281144/ introduces new callins for SG events
16:18:36 <rcurran> and then introduce that code to the ODLv2 SG code
16:19:04 <rcurran> similar to what kyle did w/ the original callback.py and test_callback.py
16:20:53 <yamahata> Sounds plausible. no reason to tie SG logic into the driver
16:21:42 <rcurran> yamahata, you mean tying the new callback.PRECOMMIT code w/ the ODL v2 SG code, correct?
16:22:12 <yamahata> rcurran: right.(Fornow) Anyway I'll review the patch and look into the code closely.
16:22:22 <rcurran> agreed
16:22:48 <yamahata> #action yamahata review https://review.openstack.org/#/c/281144/ today
16:22:55 <yamahata> anything else?
16:23:36 <yamahata> #topic ML2 ODL driver rewrite
16:23:50 <yamahata> I reviewed the 3 patches.
16:24:15 <yamahata> asomya: rcurran any updates?
16:25:07 <rcurran> i also pushed up ODLv2 SG support - https://review.openstack.org/#/c/281490/ - wrote this back in december but was waiting off so as not to distract from L3 and other bugfixes
16:25:31 <yamahata> #link https://review.openstack.org/#/c/281490/  ODLv2 SG suppor
16:25:41 <rcurran> i'd prefer to get L3 + all the bugfixes in the queue merged before pushing up reviewable version of ODLv2 SG
16:25:52 <asomya> yamahata: Everything was blocked on the UT bug, i'll asnwer the comments today
16:25:55 <rcurran> otherwise tweaks will need to be made to unit tests
16:26:06 <asomya> Also taking a look at any V1 fixes that were merged recently to port to the V2 driver
16:26:16 <yamahata> asomya: yeah, let's unblock the bug first asap
16:26:32 <yamahata> asomya: great.
16:27:35 <yamahata> anything else? or move to the next
16:28:07 <rcurran> yamahata, so will it be just you that allows code to be merged?
16:29:09 <yamahata> rcurran: yes. We need to change it. So I'm thinking of you or asomya
16:29:21 <rcurran> i vote for asomya :-)
16:30:01 <yamahata> In fact my plan was to discus with you in face-to-face manner at openstack summit. But the situation is worse than I expected
16:30:12 <rcurran> ok, i realize there are still some (minor) concerns w/ some of these patches but the sooner the code gets merged the easier it is for others to use it and add to the ODLv2 code
16:30:18 <john_a_joyce> I also vote for asomya :-)
16:30:31 <asomya> my vote goes to rcurran
16:30:43 <vthapar> +1 to asomya
16:31:50 <yamahata> #action rcurran and asomya decide which of you are taking care of the responsibility
16:31:57 <yamahata> :-)
16:32:19 <yamahata> you two can talk off line
16:32:38 <rcurran> test, vpn disconnect
16:32:41 <yamahata> oh oh. he run away :-)
16:33:22 <rcurran> man, if there was ever a sign ... that was funny, i swear i didn't disconnect on purpose
16:33:37 <yamahata> lol
16:34:15 <yamahata> anything else?
16:35:10 <yamahata> move on
16:35:16 <yamahata> #topic OpenStack release support
16:35:23 <yamahata> no update.
16:35:39 <yamahata> #topic Beryllium release preparation and Boron planning
16:35:49 <yamahata> Will any one attend opendaylight design forum?
16:36:20 <yamahata> There I'd like to come up with prioritized task list for ODL neutron northbound
16:36:35 <yamahata> Even if you won't, your input is quite important.
16:36:42 <vthapar> I won't be able to but got someone to be there on my behalf with a laundry list :)
16:36:57 <yamahata> Especially which (new) neutron feature  you want.
16:38:49 <yamahata> I suppose trello would be nice to manage those task list than wiki
16:38:56 <yamahata> So I'll create tasks based on whishlist
16:39:10 <yamahata> #link https://trello.com/b/LhIIQ8Z0/odl-neutronnorthbound trello board for ODL neutron northbound
16:39:25 <yamahata> #link https://wiki.opendaylight.org/view/NeutronNorthbound:FutureReleaseWishList#Boron wishlist for boron
16:40:05 <yamahata> We'll have sorted list of features for boron at design forum, I hope
16:41:02 <yamahata> My current analysis can be found at https://docs.google.com/presentation/d/1kq0elysCDEmIWs3omTi5RoXTSBbrewn11Je2d26cI4M/edit?usp=sharing
16:41:11 <yamahata> #link https://docs.google.com/presentation/d/1kq0elysCDEmIWs3omTi5RoXTSBbrewn11Je2d26cI4M/edit?usp=sharing boron planning/feature gap analysis
16:41:46 <yamahata> It's draft and just fuel for discussion.
16:42:27 <yamahata> As per my understanding, there are gaps for full L3 support
16:42:50 <yamahata> those needs to be addressed both in neutron side and ODL side.
16:43:30 <yamahata> #action yamahata convert wishlist into trello board card
16:43:38 <yamahata> any other comment/thought?
16:44:30 <yamahata> okay last topic
16:44:32 <yamahata> #topic open mike
16:44:44 <yamahata> whatever topics?
16:45:31 <vthapar> now that beryllium is open again, I'd like inputs on https://git.opendaylight.org/gerrit/#/c/34818/
16:46:08 <vthapar> this is another one of those code that never worked but wasn't caught coz no one is using it.
16:46:09 <yamahata> vthapar: oh yes.
16:46:40 <vthapar> yamahata: I sent out a mail explaining the issues.
16:46:56 <yamahata> #action yamahata follow up vthapar
16:47:09 <vthapar> want me to explain it here?
16:47:31 <yamahata> vthapar: please go ahead
16:47:51 <vthapar> neutron router-interface-add and delete are broken in NN.
16:48:31 <vthapar> neutron-l3.yang has interfaces list in router object which is supposed to contain list of interfaces attached to a router, but it is always empty.
16:49:05 <vthapar> the review I posted fixes part of it... but issue is some disconnect between L3 plugi on n-odl side and ODL NN code as to what a router interface is and what is the key.
16:49:42 <vthapar> router-interface-add sends an object with following fields: uuid, port-id, subnet-id and tenant-id
16:49:59 <yamahata> in neutron l3 code, the key(subnet id) isn't stored in db.
16:50:07 <vthapar> uuid is same as the router-uuid to which interface is added.
16:50:24 <yamahata> l3 plugin needs to recreate(find) subnet id somehow on resync
16:50:54 <vthapar> right now bigger problem is use of uuid as key in yang.
16:51:16 <vthapar> basically, we're using router-id as key for interfaces list. which means one router can't have more than one interface.
16:51:52 <vthapar> key should ideally be the port-id as that is the only value of the 3 that will be unique for each interface attached to router
16:52:17 <yamahata> Sounds reasonable.
16:52:32 <vthapar> fix can be done by setting changing key to port-id in yang, but a simpler thing would be for l3 plugin to fill id with port-id in first place.
16:52:52 <vthapar> interestingly, in spi/NeutronRouter we do use portID as key for interfaces list.
16:53:19 <vthapar> so, it is basically disconnect betwee NN and L3 plugin as to what is ID of a router interface.
16:53:29 <yamahata> Do you need (clean) fix in Beryllium?
16:53:41 <yamahata> We can sort it out in Boron.
16:54:01 <vthapar> we're going with a workaround for Beryllium, so can wait till Boron to fix properly.
16:54:02 <yamahata> But in Beryllium, it may require api breakage.
16:54:16 <yamahata> okay
16:54:17 <vthapar> interesting is, the workaround pulls into question why we need router-interface at all.
16:54:26 <vthapar> OVSDB netvirt has been working fine without it so far.
16:54:46 <vthapar> they listen for NeutronPort DCNs and use ownership to determine if it is router-interface add or delete.
16:54:54 <yamahata> interesting!
16:55:05 <vthapar> that is the workaround we'll be using in vpnservice for Be.
16:55:33 <vthapar> so, coming back, do we even need router interface list?
16:56:00 <vthapar> other open issue in fix I posted is how to update router with interfaces.
16:56:01 <yamahata> Yes that's certainly work around.
16:56:22 <vthapar> today I am using udpateRouter... but router interface add/delete and router update both use same methods.
16:56:27 <yamahata> But ODL neutron northbound is not only for netvirt, but also other.
16:56:45 <yamahata> So ODL NN should provide correct interface.
16:57:02 <vthapar> yes. agree.
16:57:11 <yamahata> At least ODL NN should be agnostic to service provider.
16:57:26 <vthapar> that is why we'll use workaround for Be but would prefer proper solution going forward.
16:57:46 <vthapar> we will have to refactor the update() method for router also.
16:58:04 <vthapar> when update is called for router interface add/delete, delta will have information about interfaces.
16:58:31 <vthapar> but when it is called for router update, interfaces list is empty. so any update post interface addition ends up wiping interfaces from datastore.
16:59:10 <yamahata> Probably we need to sort out not only in ODL NN, but also in neutron/networking-odl
16:59:31 <vthapar> so we need two updateDelta methods... one to be called for router update that pulls up interface information, and other for interface add/delete that uses whatever is in delta.
16:59:33 <vthapar> yes.
16:59:34 <yamahata> We need to figure out what events are generated with L3
17:00:12 <vthapar> and it brings up another important thing, need to strengthen our test cases...
17:00:31 <yamahata> I can't agree more.
17:00:32 <vthapar> we shouldn't have gone so long without discovering these basic use case issues.
17:00:53 <yamahata> time is running out...
17:00:57 <vthapar> am done :)
17:01:05 <yamahata> any other topics?
17:01:47 <yamahata> thank you everyone
17:01:52 <yamahata> #topic cookies
17:01:54 <rcurran> thanks, byte
17:01:59 <rcurran> bye
17:02:00 <yamahata> #endmeeting