15:00:27 <mlavalle> #startmeeting neutron_l3
15:00:27 <openstack> Meeting started Thu Apr  6 15:00:27 2017 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:30 <openstack> The meeting name has been set to 'neutron_l3'
15:00:52 <john-dav_> hi o/
15:00:59 <haleyb> hi
15:01:06 <mlavalle> hi
15:01:23 <mlavalle> why the john-dav_ nick today?
15:01:49 <mlavalle> #topic Announcements
15:02:19 <mlavalle> Pike-1 is almost here. Next week
15:02:28 <mlavalle> Time flies as usual!
15:02:31 <john-davidge> mlavalle: variety is the spice of life
15:02:39 <mlavalle> indeed!
15:03:07 <mlavalle> We are a month away from the Summit in Boston
15:03:29 <mlavalle> I know I will see haleyb. Hoping to see john-davidge!
15:04:02 <john-davidge> mlavalle: Still hopeful! Rackspace have still not approved any travel
15:04:22 <mlavalle> good luck with that, john-davidge!
15:04:30 <john-davidge> mlavalle: haha, thanks
15:05:46 <mlavalle> Finally, the venue / date for the Queens PTG has been announced. September 11th - 15th in Denver
15:06:10 <mlavalle> I'll start bugging my manager to get a travel approval :-)
15:06:29 <mlavalle> Any other annoucements!
15:06:33 <mlavalle> ?
15:06:45 <john-davidge> mlavalle: I can say for certain I will not be there as I leave for my honeymoon on the 16th :)
15:07:18 <mlavalle> That's a good reason, Orlando, right?
15:07:33 <haleyb> john-davidge: congrats!
15:07:34 <john-davidge> mlavalle: Yup, we're big kids
15:07:38 <john-davidge> haleyb: Thanks!
15:08:03 <mlavalle> #topic Bugs
15:08:05 <haleyb> mlavalle: i will start asking for approval (and check the calendar)
15:08:43 <mlavalle> First one is https://bugs.launchpad.net/neutron/+bug/1627424
15:08:43 <openstack> Launchpad bug 1627424 in neutron "FlushError on IPAllocation" [High,In progress] - Assigned to Miguel Lavalle (minsel)
15:09:15 <mlavalle> I proposed a patchset that I think will have impact on this bug
15:09:46 <mlavalle> It changes the way IPAllocations are associated to the port:
15:09:53 <mlavalle> #link https://review.openstack.org/#/c/452501/
15:10:30 <mlavalle> It was simpler that originally thought, thanks to the get() method in the sqlalchemy session object
15:10:42 <mlavalle> Tak a look and see what you think
15:10:51 <mlavalle> Take^^^
15:11:22 * john-davidge looking
15:11:23 <mlavalle> I am hoping kevinbenton will have some time soon to review it
15:12:47 <mlavalle> ok, moving on
15:12:57 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1610483
15:12:57 <openstack> Launchpad bug 1610483 in neutron "Pluggable IPAM rollback mechanism is not robust" [High,In progress] - Assigned to Aliaksandr Dziarkach (aliaksandr-dziarkach)
15:13:57 <mlavalle> As agreed last week during this meeting, I tried to ping johnbelamaric without success. He doesn't seem to hang out in the neutron channel regularly anymore
15:14:17 <mlavalle> So last night I sent him an email asking his opinion on the next step
15:14:35 <mlavalle> He hasn't responded yet
15:16:00 <mlavalle> Moving on
15:16:11 <mlavalle> Next up is https://bugs.launchpad.net/neutron/+bug/1627480
15:16:11 <openstack> Launchpad bug 1627480 in neutron "create_port can succeed without returning fixed_ips on all requested subnets" [High,Confirmed] - Assigned to James Anziano (janzian)
15:16:32 <mlavalle> I spent time in Kibana looking for occurences of this bug
15:16:49 <mlavalle> As of an hour ago, we had 3 hits over the past 7 days
15:17:20 <mlavalle> All of them were with the same patchset, 453431
15:18:17 <haleyb> was that patch tweaking ports?
15:18:21 <mlavalle> Which is a cherry pick to stable Newton in project openstack/puppet-aodh
15:18:45 <mlavalle> Nope, it uses Neutron stable/Newton
15:19:21 <haleyb> and it's not a neutron patch either
15:19:51 <mlavalle> so my guess is that this bug has been fixed kevinbenton's refactoring of the of subnets deletes in ml2 and DB plugin
15:20:35 <mlavalle> because there are DHCP ports creations and subnets deletes involved in the failure
15:20:38 <haleyb> yes, i think we can close it
15:21:05 <mlavalle> ok cool
15:21:48 <mlavalle> I'll make a note explaining how we reached the conclusion of closing it and then I'll close it
15:22:04 <mlavalle> sounds good haleyb?
15:22:15 <haleyb> ack
15:22:33 <mlavalle> The last one for today is https://bugs.launchpad.net/neutron/+bug/1509004
15:22:33 <openstack> Launchpad bug 1509004 in neutron ""test_dualnet_dhcp6_stateless_from_os" failures seen in the gate" [High,Confirmed] - Assigned to James Anziano (janzian)
15:23:03 <mlavalle> Didn't have time to look at this one. Since I will be closing the previous one soon, I'll give this one some TLC next
15:23:22 <mlavalle> Any other comments?
15:24:16 <mlavalle> Any other bugs from the team?
15:25:22 <mlavalle> ok, moving on
15:25:32 <mlavalle> #topic DVR non-voting job
15:26:08 <haleyb> i just added an item for that on the etherpad
15:26:27 <mlavalle> haleyb: this is the topic about the non-voting job that ihrachys brought up
15:26:34 <mlavalle> yeah
15:26:37 <mlavalle> great
15:26:55 <mlavalle> so how do we move forward with this?
15:26:58 <haleyb> yes.  there is actually an experimental job i had forgotten about
15:28:10 <haleyb> i think the plan can be move that one to take the place of the dvr-multinode one - they are both non-voting now anyways
15:28:46 <haleyb> then update grafana dash, etc, so we can see how it goes
15:28:48 <mlavalle> is that something you will do or you need some help?
15:29:19 <haleyb> i can give it a try, of course i might be missing some step that i will learn about along the way
15:29:37 <mlavalle> ok, cool
15:30:02 <mlavalle> and we can report back to the Neutron CI team during the Tuesday meeting
15:30:52 <haleyb> yes. i'll get a review out to swap the two, i can't imagine we'd want to have both non-voting due to resource contraints
15:31:19 <haleyb> actually, we can probably just retire the existing one
15:31:27 <mlavalle> yeah, that makes sense
15:32:06 <haleyb> i'll ping ihar about it once i get the patch together
15:32:17 <mlavalle> Thanks!
15:32:39 <mlavalle> Moving on
15:32:56 <mlavalle> #topic Routed Networks
15:33:18 <mlavalle> john-davidge: we didn't get to the RFE last week during the drivers meeting
15:33:44 <john-davidge> mlavalle: Do you think there would be some value in getting started on a WIP before it's been approved?
15:33:48 <john-davidge> mlavalle: I have the cycles
15:34:01 <mlavalle> Yes, I think so
15:34:15 <john-davidge> mlavalle: Ok, I'll do that then
15:34:26 <john-davidge> mlavalle: thanks
15:34:41 <mlavalle> I also want to contribute to that, so maybe we can coordinate outside this meeting
15:34:50 <mlavalle> john-davidge ^^^
15:35:21 <john-davidge> mlavalle: Sure, perhaps I'll work on a first draft and ping you if I hit any roadblocks?
15:35:33 <mlavalle> ]That makes sense
15:35:58 <mlavalle> Moving on
15:36:07 <mlavalle> #topic Open Agenda
15:36:19 <mlavalle> Any other topics we should discuss today?
15:37:17 <ibmko> hello, if no topics, I would have one general question about L3 in neutron
15:37:33 <mlavalle> ibmko: sure
15:38:09 <ibmko> is it possible with current neutron API to develop neutron routers backed by nova instances ?
15:38:50 <mlavalle> Do you mean the router implemented by a Nova instance?
15:38:56 <ibmko> yes
15:39:44 <ibmko> I am looing at it a bit and it seems rarther problematic given that both the router object as well as the nova instance has to have neutron ports allocated and connected to desired networks
15:39:57 <mlavalle> From the purely API point of view, it might be possible
15:40:20 <mlavalle> But you will have to completely change what is behind the API
15:40:20 <haleyb> not via the API, but you can deploy an openstack cloud on an openstack cloud if that's what you want
15:40:26 <ibmko> and these ports are supposed to be "same" ports with same IP adressess
15:41:22 <haleyb> mlavalle: what i'm saying is you can create a neutron router that happens to be inside a nova instance, but neutron doesn't know that
15:41:31 <ibmko> haleyb, thats probably not what we need, we just need routers (or generally L3 devices) which are normal virtual routers and not namespaces on network node nor DVR
15:41:58 <mlavalle> haleyb: yeah, I see what you say
15:42:31 <mlavalle> But I think that what ibmko is saying is that he wants to re-use the API calls to implement routers in a completely different way
15:43:01 <mlavalle> so he needs to change what lies behind the API
15:43:24 <mlavalle> ibmko: did I get you right?
15:43:43 <ibmko> yes, well, I was hoping that neutron just defines L3 API and lets people to implement it whatever the way they need, but it doesn't seem to provide this flexibility
15:44:34 <mlavalle> ibmko: that is the intent of the plugin architecture
15:44:45 <ibmko> right
15:45:00 <mlavalle> in fact, in the reference implementation, L# is implemented by a service plugin
15:45:18 <ibmko> and given our specific implementation desire - to use nova instances as routers - do you see some viable way witnout breaking the API ?
15:45:38 <ibmko> I think from the API point of view, following thing is problematic:
15:45:49 <mlavalle> ibmko: see here https://github.com/openstack/neutron/tree/master/neutron/services/l3_router
15:46:19 <ibmko> the api defines "add_router_interface"
15:46:26 <ibmko> and this api says: If the port is already in use, this operation returns the Conflict (409) response code.
15:46:46 <ibmko> this is I think what prevents us from doing nova based routers
15:46:53 <mlavalle> ibmko: keep in mind that Neutron's routers are not general purpose L3 routers
15:47:13 <ibmko> mlavalle, yeah, this is something I am starting to realize
15:47:43 <ibmko> but even with limited scope of what  the neutron router is, it might make sense to implement it using nova instance
15:48:07 <mlavalle> yeah, in principle
15:49:12 <mlavalle> anything else?
15:49:16 <haleyb> i think that's possible, but you would have to manage it yourself.  in the "old days" my company had notes on creating such things (two ports, no security groups), and having it be the router, but neutron router* commands didn't manage it
15:49:35 <mlavalle> correct
15:49:39 <haleyb> for example, the old vpn code was like that
15:49:48 <mlavalle> because the semantics change
15:50:20 <ibmko> so probably there is no way now of having nova instance under semantics of neutron router API ?
15:50:57 <ibmko> btw brocade vyatta did that two years ago
15:51:19 <mlavalle> I don't think the problem is the Nova implementation itself
15:51:45 <ibmko> but I think it is abandoned and they must have hacked something in too in order to make it work
15:51:54 <mlavalle> The problem is what you want that router to do for you aqnd that, with the current API, you don't have the semantics to manage that
15:52:35 <mlavalle> Of course you are going to have to coordinate with Nova in your backend (what lies below the API)
15:53:03 <mlavalle> send requests to NOva to create the instance for the router
15:53:37 <mlavalle> You can also explore the possibility of an API extension
15:53:39 <ibmko> mlavalle, I can imagine that the management of it can be doable, but where I see the main problem is that current neutron L3 API requires neutron port to be connected to the router object but if the router is represented by nova instance, this nova instances needs the very same neutron port connected too otherwise it cannot communicate into the netwrok
15:54:52 <mlavalle> In Neutron, to give a port to an instance, you don't need L3
15:55:22 <mlavalle> a port is a core resource and is really managed at L2
15:55:34 <ibmko> mlavalle, uh not sure i understand
15:55:57 <mlavalle> L3 comes into play when you want routers, floating ip's and snat
15:56:06 <ibmko> I know that
15:56:41 <mlavalle> so you could propose an extension API
15:56:56 <mlavalle> Let's call it Real Routers extension API
15:57:06 <ibmko> but the router object requires a neutron port when calling add_router_interface, and if router is implemented by nova instance, this nova instance needs a port (with same IP adress) too
15:57:10 <ibmko> and that is a conflic
15:57:12 <mlavalle> where you define your API calls with the semantics you need
15:57:13 <ibmko> conflict
15:58:04 <mlavalle> and then you implement the real router anyway you want
15:58:15 <ibmko> right
15:58:19 <mlavalle> Current Neutron's L# API is itself an extension API
15:58:25 <mlavalle> L3^^^
15:58:52 <mlavalle> Take a look: https://github.com/openstack/neutron/blob/master/neutron/extensions/l3.py
15:58:59 <ibmko> ok
15:59:17 <mlavalle> And after saying this, I will close the meeting because in 1 minute another one is going to start
15:59:31 <ibmko> thank you very much
15:59:36 <mlavalle> I don't want to piss-off cdent or edleafe
15:59:39 <haleyb> bye
15:59:40 <mlavalle> #endmeeting