14:00:08 <mlavalle> #startmeeting neutron_drivers
14:00:09 <openstack> Meeting started Fri Nov 30 14:00:08 2018 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:12 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:20 <mlavalle> Hi there
14:00:41 <klindgren> o/
14:00:58 <mlavalle> good morning klin
14:01:05 <yamamoto> hi
14:01:21 <mlavalle> good earlu monring klindgren
14:01:21 <amotoki> o/
14:01:50 <klindgren> mlavalle, Thanks.
14:01:59 <mlavalle> let's give haleyb and slaweq a minute to join
14:02:13 <slaweq> hi
14:02:17 <slaweq> sorry for being late
14:02:23 <njohnston> openstackbot having issues?
14:02:55 <haleyb> hi
14:03:03 <mlavalle> ok let's get going
14:03:04 <amotoki> njohnston: is there any issue you see?
14:03:18 <mlavalle> #topic RFEs
14:03:54 <mlavalle> First one is https://bugs.launchpad.net/neutron/+bug/1764738
14:03:55 <openstack> Launchpad bug 1764738 in neutron "routed provider networks limit to one host" [Wishlist,New]
14:05:03 <wwriverrat> Was Kris able to join (bug creator)? I know had planned to :)
14:05:16 <klindgren> I am here
14:05:42 <mlavalle> THis one was originally proposed back in April by an operator in Sweden. Last week, in a conversation with klindgren we discovered his employer (GoDaddy?) has the same need
14:06:08 <njohnston> o/
14:06:20 <klindgren> I also made a post to the openstack-discuss mailing list - but I don't think everyone has moved over to that.
14:06:20 <klindgren> http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000082.html
14:08:28 <amotoki> in my rough understanding, this RFE request segments per provider network, while host to segment binding is global now. right?
14:09:06 <klindgren> I believe our needs a similar but slightly different, so I wanted to call out our similar use case.  Mainly that we have a need to attach a server to multiple segments of a routed network.  The primary reason being that with our network design the L2 doesn't leave the top of rack.  But we are getting to the point where we are deploying more vm's into a rack than our networking team wants to give ip's for on a single vlan.  So they want to expos
14:09:06 <klindgren> e the additional ip's on another vlan.  Which in routed networks would be another segment.
14:10:18 <amotoki> so my understanding seem not correct.
14:11:43 <mlavalle> in other words, to actually be able to achieve to exploit the benefits of routed networks (i.e. small L2 domains + scalability though L3 routing) you need more than one segment of the routed network to connect to the each compute. Is that a good summary
14:12:08 <mlavalle> ?
14:12:26 <klindgren> Yes exactly
14:13:02 <klindgren> Our networking team is refusing to add more than a /22 worth IP address spacing to a vlan, due to fear of broadcast domain issues.
14:13:37 <klindgren> But they would happily do 10 vlans each with a /22 on the same switch.
14:13:48 <mlavalle> that makes sense. one of the tenets of routed networks is to have small l2 broadcat domains
14:14:21 <slaweq> ok, I think I understand this rfe now, but I'm not an expert in routed networks so I have one, maybe not very good question: why it was limited originally? are there any potential technical issues with doing it?
14:14:26 <mlavalle> if you start assigning big broadcat domains to the segments, we are back with the original problem
14:15:03 <klindgren> The limit was original put in by carl Baldwin who did the original routed network stuff with a comment
14:15:39 <klindgren> That basically says, we don't fully understand the use cases for multiple segments, so to simplify we are imposing an assumption that a host will be bound to only one segment
14:16:03 <klindgren> And that the restriction could be relaxed as those use cases are understood
14:16:27 <slaweq> klindgren: ok, thx, and now we have such use case for it :)
14:16:35 <slaweq> I see now
14:16:38 <amotoki> vlan is mapped to a segment and if you introduce a new vlan for a same range of your L2 network it sounds reasnable to define a new segment and assign it to an existing host.
14:17:51 <mlavalle> at the moment of implementing originally routed networks, we didn't know the limits
14:18:27 <mlavalle> so to simplify the implementation we made the assumption, somewhere in the IPAM, of only one segment per compute
14:18:40 <mlavalle> and we expected to have operator feedback
14:18:46 <mlavalle> which is now happening
14:19:05 <klindgren> As I am working through this locally I am running into some issues, that I am working through on fixing.  Their are seemingly 2 problems.
14:19:43 <amotoki> one question: if one host belongs to multiple segments of a routed network, how can we select an appropriate segment for a new VM?
14:19:57 <mlavalle> amotoki: that's part of the problem
14:20:05 <mlavalle> you got it
14:20:21 <klindgren> One is that when you have multiple segments on a host and you try to bind a port from the second segment.  The information that is sent to the agent contains the binding information of the first bindable segment.
14:20:46 <klindgren> So in routed networks the subnet is assigned to the segment.
14:20:53 <mlavalle> https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mech_agent.py#L106-L110
14:21:18 <klindgren> So if you know the subnet the ip came from - you should already know segment that should be bound for it.
14:22:09 <mlavalle> yes, that problem seems solvable
14:22:37 <slaweq> if we are talking about scheduling, should placement be involved in this somehow maybe?
14:22:51 <mlavalle> slaweq: it is already involved
14:23:10 <wwriverrat> One thing klindgren and I were looking at:... when you push information down to the agent, you'd include the segment_id with the port. Maybe using the segment_id (not to be confused with segmentation_id) to plug with rather than the network ID.
14:23:29 <mlavalle> part of the routed networks implementation was to create an IPV4 inventory in placement
14:23:50 <klindgren> However, in the data that is passed around the segment_id is basically been stripped out.  Which also leads to a second problem.  If you are trying to use the vlan driver.  And you get it to give the correct binding information for the second segment.   Since the name of the bridge is done via the network_id.  Both segments are part of the same network, and have the same network id
14:23:51 <slaweq> ahh, ok mlavalle
14:24:01 <klindgren> So it joins them both to the same bridge
14:24:15 <klindgren> When it really needs to be different bridges for each segment.
14:25:12 <mlavalle> klindgren: is this second hurdle to avoid L2 conflicts?
14:26:01 <klindgren> I just don't see how it wouldn't spill traffic across the vlans
14:26:17 <klindgren> Or even possibly create a spanning tree loop?
14:26:31 <klindgren> IE:
14:26:31 <klindgren> -bash-4.2# brctl show
14:26:31 <klindgren> <snip>
14:26:31 <klindgren> brq3188bc9c-49                                8000.9e8444c8e353       no                           br0.401
14:26:31 <klindgren> br0.402
14:26:32 <amotoki> the second problem seems that we need to decide vlan ID for a port based on a combo of (network ID and segment ID), right?
14:26:33 <klindgren> tap1789c805-1c
14:26:38 <klindgren> tap770e7357-be
14:26:41 <klindgren> <snip>
14:27:06 <mlavalle> yes, that's what I meant, potential spaning tree loop
14:27:35 <klindgren> The vlan id comes from the segment and is populated into the device_info from information from the segment
14:27:50 <mlavalle> ok, based on this, here's what I propose:
14:28:46 <mlavalle> 1) The use case / need is pretty clear. It was even predicted in the original routed networks implementation. So my proposal is to approve this RFE
14:29:41 <mlavalle> 2) Frequently, when we approve a RFE, we request a spec. But I don't think that applies here. We know the what well. Where we seem to be struggling is the how
14:30:22 <mlavalle> I think klindgren and wwriverrat have made a good job identifyin the "hot spots" in the code
14:30:54 <mlavalle> I propose to push a patch with PoC code
14:31:26 <mlavalle> that will help us, as a team, cooperate in solving the technical issues
14:31:44 <mlavalle> The code you are experimenting with is a good starting point
14:31:52 <slaweq> +1, it will be easier to see in PoC how those problems are solved
14:31:54 <yamamoto> isn't a spec for the how?
14:33:01 <mlavalle> yamamoto: mhhhh.... let's not get bogged down in terminology. some what and shome how
14:34:18 <mlavalle> in this case, given where we are, I think a PoC would be more enlightening
14:34:21 <yamamoto> i'm not against poc as far as we will have devref or spec in the end
14:34:29 <amotoki> I think RFE is to discuss what is needed and a spec is to discuss how it can be achieved. (the how includes what should be changed)
14:34:57 <amotoki> basically +1 for the proposal. PoC should work in this case.
14:35:44 <klindgren> Ok - I can push some PoC code here hopefully early next week, with what we did to get it working for our use case.  I fully expect some parts need to be complexly re-worked.
14:36:15 <amotoki> one question: can this effort be done only inside neutron? is there no change in the placement side? If we need a chnage in placemment we need a pace to write down the whole picture of the chagne.
14:36:38 <mlavalle> klindgren: hang on, let's make sure we have consensus
14:37:52 <mlavalle> I think yamamoto and amotoki pojnt about the spec is also justified
14:38:11 <mlavalle> I might have used wrong phrasing
14:38:30 <mlavalle> let's use the PoC to uncover the challenges
14:38:57 <mlavalle> and we re-group in a few weeks and see where we are are on possible impacts to Nova
14:39:10 <mlavalle> as far as I can tell now, there shouldn't be impact
14:39:28 <klindgren> I honestly am not sure on the placement side.  Right now I have just been trying to boot the second vm with a port that I already created on the second network.  That part *does* seem to work.  But I also wanted to confirm this works organically, as well.
14:39:29 <mlavalle> because we already hva the IPv4 inventories in placement
14:39:57 <mlavalle> but the PoC work might help uncover potential issues
14:40:18 <mlavalle> and at that point we can take the learning and write up a spec
14:40:22 <mlavalle> does that work?
14:40:25 <amotoki> mlavalle: the above makes sense to me
14:40:31 <slaweq> +1
14:40:41 <yamamoto> +1
14:41:37 <mlavalle> does that work for you klindgren and wwriverrat?
14:41:49 <klindgren> Yes it does
14:41:49 <wwriverrat> +1 from me :)
14:42:05 <mlavalle> haleyb: any thoughts?
14:43:37 <mlavalle> let's assume he is ok
14:43:43 <njohnston> I'm just spectating, but having worked in enterprises where the typical VLAN IP allocation size was /27 it makes total sense to me.
14:44:07 <haleyb> sorry, was looking at something else
14:44:37 <haleyb> i'm ok with what you decide
14:45:22 <mlavalle> njohnston: absolutely. I think we are at a point where the routed networks original implemantation is meeting the reality and we need to incorporate the feedback of that reality to make this feature reach its potential
14:46:30 <mlavalle> klindgren, wwriverrat: thanks for your feedback. I personally struggled a bit with the original form of that RFE, and your feedback was very valuable
14:47:04 <klindgren> No problem, thank you guys for your time.
14:47:16 <mlavalle> I'll capture the decision in the RFE and will mark it as approved
14:49:36 <mlavalle> klindgren, wwriverrat: I'll leave also a pointer in the RFE to the message in the ML as a reference
14:49:57 <wwriverrat> awesome
14:51:08 <mlavalle> Next one to discuss in the list is https://bugs.launchpad.net/neutron/+bug/1793653
14:51:09 <openstack> Launchpad bug 1793653 in neutron "[RFE] Enable other subprojects to extend l2pop fdb information" [Wishlist,In progress] - Assigned to ChenjieXu (midone)
14:51:58 <Chenjie> mlavalle:thanks!
14:52:27 <mlavalle> we might not have time to finish the discussion, but at least we can set it up for next week
14:53:10 <Chenjie> ok
14:53:20 <slaweq> IIRC it was already discussed few weeks ago
14:53:34 <slaweq> yamamoto: did You get any feedback from ODL team?
14:53:44 <mlavalle> yes, and Chenjie provided feedback in the RFE that now we have to digest
14:54:18 <yamamoto> slaweq: no
14:54:47 <slaweq> yamamoto: ok, I just remember that we talked about it, right?
14:55:21 <mlavalle> yamamoto: yamahata and manjeets are closer to my time zone than yours. I can take that action time
14:56:12 <yamamoto> slaweq: i pinged yamahata and he said he would talk with relevant folks. i haven't heard anything since then.
14:56:48 <yamamoto> mlavalle: sure, i guess it works better
14:56:54 <slaweq> sure, no problem :) I just wanted to ask if You have anything
14:57:02 <mlavalle> yamamoto: cool
14:57:28 <slaweq> IIRC this was our biggest concern, if we should provide some abstraction for such stadium projects, right?
14:57:52 <mlavalle> yes
14:58:05 <slaweq> ok
14:58:37 <mlavalle> Chenjie: thanks for the feedback provided in the RFE. There is a lot to digest there
14:58:52 <yamamoto> slaweq: yes. i still struggle to understand how it can work but i guess it's just me.
14:58:54 <mlavalle> we will start the meeting with this RFE next week
14:59:22 <slaweq> fine for me
14:59:25 <Chenjie> mlavalle: thank you so much!
14:59:46 <Chenjie> everyone, thank you for your time!
14:59:47 <mlavalle> yamamoto: your concerns are always important in this team
15:00:08 <mlavalle> #endmeeting