14:00:04 <mlavalle> #startmeeting neutron_drivers
14:00:05 <openstack> Meeting started Fri Aug 16 14:00:04 2019 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:08 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:13 <njohnston> o/
14:00:36 <slaweq> hi
14:01:10 <mlavalle> let's wait a couple of minutes
14:07:35 <mlavalle> mhhhh, maybe the others are off today
14:07:45 <mlavalle> amotoki most likely
14:08:18 <mlavalle> let's wait a few more minutes
14:09:08 <haleyb> hi
14:09:14 <mlavalle> there he is
14:09:23 <mlavalle> now we have quorum
14:09:29 <slaweq> \o/
14:09:30 <haleyb> there was a shiny object nearby :)
14:09:40 <mlavalle> so let's get going
14:10:04 <mlavalle> #topic RFEs
14:10:14 <mlavalle> we will start today with https://bugs.launchpad.net/neutron/+bug/1832526
14:10:15 <openstack> Launchpad bug 1832526 in neutron "[RFE] Network segmentation support for edge deployments" [Wishlist,New]
14:14:09 <slaweq> mlavalle: I have some questions to Your last comment in this RFE
14:14:16 <mlavalle> sure
14:14:35 <slaweq> mlavalle: about point "2. Admin creates a Neutron network associated with the "Small Edge" host" -- isn't this done already by bridge mappings?
14:15:23 <mlavalle> yes and no
14:15:27 <njohnston_> reading your analysis on the bug mlavalle it strikes me that this is really a subset or a special case of availability zones, is it not?
14:16:27 <slaweq> and informations about bridge_mappings are already send to the placement with info about bandwidth, am I right?
14:17:14 <mlavalle> yes, but are you suggesting that this has to be associated with QoS?
14:18:24 <mlavalle> so some of the mechanisms may be already in place, but I think we need to repurpose them for this use case
14:18:24 <slaweq> mlavalle: no, just saying that this should be eventually easy to accomplish as we have necessary bits already
14:18:37 <slaweq> IIUC of course :)
14:19:01 <mlavalle> I think we are saying the same thing
14:19:18 <mlavalle> much of the machinery is in place, but we need to adapt it
14:19:30 <slaweq> ok
14:19:51 <mlavalle> njohnston_: I hadn't thought of that perspective
14:20:54 <mlavalle> but maybe taking that perspective might help us... tell me more please
14:21:25 <mlavalle> slaweq: good points though
14:22:54 <njohnston> mlavalle: Well the thrust of AZ is that instead of a single L2 domain spanning the entire region, L2 domains are bounded by the AZ which correlates to a specific set of compute/network capacity
14:23:40 <mlavalle> so one availability zone per "Small edge"?
14:24:38 <njohnston> yes, precisely.  The biggest hint that this RFE aligns with AZs is the explicit statement that connectivity between small edge sites cannot be guaranteed, which matches up with how the mesh does not stretch across AZ boundaries
14:25:22 <mlavalle> so if we take that perspective, do we get this RFE for free?
14:25:52 <njohnston> I am thinking it through but I don't see any gaps yet
14:25:57 <slaweq> I don't think we will have this RFE for free then
14:26:56 <njohnston> I'm not an expert in availability zones so I am glad for those with more expertise to weigh in
14:26:58 <slaweq> as now networks in neutron are not aware of availability zone and can works in many zones, so still You will need IMO some mechanism to assign network to the AZ, right?
14:27:30 <mlavalle> slaweq: that is also my understanding
14:27:32 <slaweq> currently in Neutron only L3 and DHCP agents are somehow aware of AZs but I'm not sure exactly how this works tbh
14:28:17 <njohnston> Isn't there a network_availability_zone extension that provides support of availability zone for networks?
14:28:29 <njohnston> https://docs.openstack.org/api-ref/network/v2/?expanded=list-all-availability-zones-detail#network-availability-zone-extension
14:29:03 <slaweq> njohnston: tbh I don't know :)
14:29:20 * mlavalle looking quickly at the code
14:29:28 <slaweq> one more thing, there is also this rfe https://bugs.launchpad.net/neutron/+bug/1808062 which might be somehow related to what we are discussing now
14:29:29 <openstack> Launchpad bug 1808062 in neutron "[RFE] Limit VXLAN to within Neutron availability zones" [Wishlist,New] - Assigned to Kailun Qin (kailun.qin)
14:30:18 <njohnston> slaweq: Yes, I was thinking about that RFE, I was not sure if that had been implemented yet.  I think that would be necessary.
14:33:16 <mlavalle> here's the extension definition in nuetron-lib https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/network_availability_zone.py
14:34:20 <slaweq> so IIUC this availability zones for networks can be used to assign it to proper dhcp agent
14:34:33 <slaweq> and router to proper L3 agent
14:35:20 <slaweq> according to https://github.com/openstack/neutron/blob/0cde163967e6b1d3f7bc499dfbfbdd2c7e09930b/doc/source/admin/config-az.rst
14:35:49 <mlavalle> looking at the code it seems it is only used for agents
14:36:41 <slaweq> but maybe this rfe can be driven in this direction to extend usage of availability zones concept there
14:36:56 <njohnston> Hmm, it just occurred to me - in it's interactions with neutron, is placement AZ-aware?
14:37:08 <mlavalle> https://github.com/openstack/neutron/blob/master/neutron/db/agentschedulers_db.py#L492
14:37:38 <njohnston> I like framing this as an AZ solution because it is a generalized solution that helps edge but also can be applied in other solutions.
14:38:08 <mlavalle> so yeah, I agree that the AZ approach framing gives us a more generalized approach
14:38:25 <mlavalle> so it boils down to what we said earlier....
14:38:52 <mlavalle> we have bits and pieces that we have to put together to meet this RFE / use case
14:38:59 <mlavalle> right?
14:39:17 <slaweq> that is at least my understanding of this rfe
14:39:37 <mlavalle> and then we need to make sure that the placement / Nova scheduler is aware
14:39:54 <mlavalle> placement / Nova scheduler comobo^^^^
14:40:01 <njohnston> +1
14:41:08 <slaweq> and if we would somehow reuse concept of AZs in Neutron, there would be no API changes required, right?
14:41:43 <mlavalle> most likely, but let's leave it as an open question
14:42:23 <slaweq> +1
14:43:01 <mlavalle> given that we need anyway to get the Nova / Placement combo guys on board, here's what I propose:
14:43:25 <mlavalle> 1) Since the use case makes sense, let's approve the RFE, with the understanding that:
14:44:01 <mlavalle> 2) We will write a spec to explore how to weave all the pieces together and identify gaps. This might involve a PoC
14:44:51 <mlavalle> 3) Let's try to make progress in the spec in time to discuss it in Shanghai in the session with Nova / Placement
14:45:14 <mlavalle> 4) I volunteer to work on 2 and 3
14:45:47 <njohnston_> +1
14:45:50 <slaweq> +1, sounds like a plan :)
14:49:49 <mlavalle> what do you think haleyb?
14:50:18 <haleyb> +1 from me
14:50:24 <mlavalle> cool
14:50:29 <mlavalle> approved it is
14:51:03 <mlavalle> next one for today is https://bugs.launchpad.net/neutron/+bug/1837847
14:51:04 <openstack> Launchpad bug 1837847 in neutron "[RFE] neutron-vpnaas OpenVPN driver" [Wishlist,Triaged]
14:51:16 <mlavalle> we discussed it last week
14:51:29 <mlavalle> and yamamoto posted questions
14:51:38 <mlavalle> which the submitter responded
14:52:06 <mlavalle> submitter will be off the next two weeks, so we have time to look at his response carefully
14:52:21 <mlavalle> why don't we do that and come back to it next week?
14:53:16 <njohnston_> makes sense
14:54:04 <slaweq> I will try to read it today and I will wrote a comment if I will have anything to add there
14:54:22 <mlavalle> yes, I know slaweq will be off the next two weeks
14:54:30 <mlavalle> don't worry too much about it
14:54:41 <slaweq> mlavalle: actually next week only regarding this meeting
14:54:52 <slaweq> I should be back on meeting in 2 weeks :)
14:54:55 <mlavalle> ahhh, good to know
14:55:07 <mlavalle> anyways, enjoy the beach!
14:55:19 <mlavalle> and the family!
14:55:24 <slaweq> thx a lot
14:55:43 <mlavalle> ok team
14:55:52 <mlavalle> great discussion today
14:56:15 <mlavalle> I think we made a lot of progress as team with the edge case
14:56:31 <mlavalle> have a great weekend!
14:56:40 <slaweq> thx, You too :)
14:56:40 <njohnston_> o/
14:56:43 <mlavalle> #endmeeting