14:00:19 <mlavalle> #startmeeting neutron_drivers
14:00:20 <openstack> Meeting started Fri Jan 25 14:00:19 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:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:23 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:28 <njohnston> o/
14:00:39 <slaweq> hi
14:01:03 <mlavalle> o/
14:01:22 <mlavalle> we know amotoki won't be able to join today
14:01:31 <mlavalle> neither haleyb
14:02:16 <slaweq> so we are waiting for yamomoto :)
14:02:24 <mlavalle> pretty much
14:08:47 <yamamoto> hi
14:08:58 <mlavalle> hi yamamoto
14:09:03 <mlavalle> good to see you
14:09:10 <slaweq> hi
14:09:24 <yamamoto> sorry for being late
14:10:05 <mlavalle> This is what we have to discuss today:
14:10:11 <mlavalle> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe-triaged
14:10:19 <mlavalle> let's get going
14:10:29 <mlavalle> #topic RFEs discussion
14:10:56 <mlavalle> From the top of the list, let's revisit https://bugs.launchpad.net/neutron/+bug/1808062
14:10:57 <openstack> Launchpad bug 1808062 in neutron "[RFE] Limit VXLAN to within Neutron availability zones" [Wishlist,New]
14:12:09 <haleyb> mlavalle: sorry i'm late
14:12:29 <mlavalle> haleyb: hey good to see you. we are discussing ^^^^
14:12:32 <mlavalle> just started
14:18:21 <slaweq> about this vxlan limit to one AZ, I think that this makes sense but IMO it will require quite big changes, like connect network with specific AZ, changes in the way how vxlan endpoints are "calculated" and so on
14:19:06 <mlavalle> yeah, if approved, we are going to need a spec
14:19:12 <slaweq> also what in case if on one host there will be 1 VM connected to such "separate AZ" network - so vxlan tunnels have to be limited only to this AZ
14:19:32 <slaweq> and also if there will be on this host vm connected to other network which isn't limited to one AZ
14:19:58 <slaweq> as You said mlavalle, I think we need spec for that as it's pretty complex change IMHO
14:20:50 <mlavalle> but conceptually I think it makes sense, especialy in light of the trend towards edge computing, which the RFE seems to reflect
14:21:29 <slaweq> mlavalle: I agree
14:21:43 <haleyb> yes, it seems good overall to me, drilling down into the details in a spec would be good
14:21:45 <slaweq> this makes sense but there is a lot of things to consider
14:25:19 <mlavalle> any thoughts yamamoto?
14:26:39 <yamamoto> is it specific to vxlan?
14:27:07 <mlavalle> yes
14:28:26 <yamamoto> how? the concept looks tunneling protocol agnostic
14:29:21 <mlavalle> well yeah, once you get to the description, seems tunneling protocol agnostic
14:29:43 <mlavalle> he chose to to scope it to vxlan in the title, though
14:30:01 <mlavalle> you have a point
14:30:48 <yamamoto> i don't think it makes much sense to have rfes for each protocols
14:31:09 <mlavalle> you are right
14:31:27 <mlavalle> we can request the spec to be written having tunnels in general as the scope
14:32:20 <yamamoto> i guess it's ok for the submitter as he seems interested in geneve as well
14:33:01 <mlavalle> yes, there is a separte rfe that mentions geneve, although he scoped that one for ovn exclusively
14:33:32 <mlavalle> but again, we can request the spec to be developed for tunnels in general
14:35:09 <yamamoto> the use case makes sense
14:35:46 <yamamoto> i'm not sure if (ab?)using az is the best way though
14:36:34 <mlavalle> what would you suggest?
14:37:12 <yamamoto> i have no alternative suggestion right now
14:37:58 <mlavalle> so maybe let's move ahead requesting a spec so we can dig further and have a discussion with the broader community.
14:38:01 <mlavalle> makes sense?
14:38:09 <yamamoto> yes
14:38:14 <slaweq> yes
14:38:18 <mlavalle> cool
14:38:36 <mlavalle> let me leave a comment in there
14:40:11 <mlavalle> done
14:40:42 <mlavalle> next one in the list is https://bugs.launchpad.net/neutron/+bug/1809037
14:40:43 <openstack> Launchpad bug 1809037 in neutron "[RFE] Add anti_affinity_group to binding:profile" [Wishlist,Triaged] - Assigned to Hongbin Lu (hongbin.lu)
14:43:58 <slaweq> is it only matter of adding information to binding:profile in port? Or some bigger changes on Neutron side are required? e.g. reporting to nova/placement about what PFs are no host or somethig like that
14:44:35 <mlavalle> it seems it is only adding informnation to the binding profile
14:45:39 <slaweq> if that would be all to do on our side, then it would be great :)
14:45:40 <mlavalle> there is no need to count resource consumption, so placement is not needed
14:46:02 <slaweq> but nova don't need to know how many PFs is still available on host?
14:46:13 <slaweq> how nova will schedule instance to good host?
14:48:41 <yamamoto> is this the right nova spec for this? https://review.openstack.org/#/c/626055/
14:49:10 <mlavalle> ahh, you beat me to it
14:49:16 <mlavalle> yes, it seems it is
14:50:51 <slaweq> ok, so it looks that nova will somehow handle that :)
14:51:14 <mlavalle> yes, looking here, it seems that is the case: https://review.openstack.org/#/c/626055/8/specs/stein/approved/sriov-bond.rst@52
14:51:52 <slaweq> if so, I'm ok with adding such field to port's binding:profile
14:52:46 <mlavalle> yes, seems a simple change for us
14:53:08 <mlavalle> so I think we can move ahead with it
14:53:49 <slaweq> +1
14:54:50 <yamamoto> give me a few min
14:55:00 <mlavalle> sure
14:55:44 <mlavalle> any thoughts haleyb?
14:56:34 <yamamoto> +1
14:56:35 <haleyb> mlavalle: sorry, someone was asking a question here...
14:56:51 <mlavalle> no problem haleyb
14:57:11 <haleyb> +1 from me
14:57:26 <mlavalle> ok so we can move ahead with this one
14:57:51 <mlavalle> since we are close to the top of the hour, I'll use the remaning few minutes to leave a comment in the RFE
14:57:58 <mlavalle> THanks for attending
14:58:07 <yamamoto> thank you
14:58:10 <mlavalle> see you next week, same time, same channel
14:58:10 <slaweq> thx, have a great weekend guys :)
14:58:16 <mlavalle> have a great weekend
14:58:25 <mlavalle> #endmeeting