14:00:04 <mlavalle> #startmeeting neutron_drivers
14:00:05 <openstack> Meeting started Fri Oct  5 14:00:04 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: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:29 <yamamoto> hi
14:00:31 <manjeets_> Hi
14:00:36 <munimeha1> hi
14:00:44 <slaweq> hi
14:01:12 <mlavalle> how are y'all?
14:01:13 <amotoki> hi
14:01:19 <slaweq> great
14:01:20 <haleyb> hi
14:01:26 <slaweq> it's almost weekend \o/
14:01:34 <mlavalle> ok, we have everybody now
14:01:40 <mlavalle> Let's get rolling
14:01:49 <mlavalle> #topic RFEs
14:02:32 <mlavalle> Let's revisit the one we discussed at the end of our last meeting: https://bugs.launchpad.net/neutron/+bug/1784879
14:02:32 <openstack> Launchpad bug 1784879 in neutron "Neutron doesn't update Designate with some use cases" [Wishlist,Triaged]
14:02:44 <njohnston> o/
14:03:18 <mlavalle> we got feedback from one of the people previously participating in the discusion in the bug
14:03:49 <slaweq> but not from reported of the issue
14:04:04 <mlavalle> it seems our approach to add dns_publish_fixed_ip was well received
14:04:34 <mlavalle> correct, the original reporter hasn't provided any feedback
14:06:23 <mlavalle> although in note #5 he seems ok with adding the attribute to any of the resources: ports, subnets or networks
14:07:15 <mlavalle> should we wait a little longer to see if we get more ffedback from him?
14:07:48 <slaweq> from comment #5 I understand that he is fine with adding this attribute to each of resources
14:08:06 <slaweq> but maybe we should wait for his feedback about adding it only to subnet
14:08:30 <mlavalle> I am also fine with waiting
14:09:31 <yamamoto> i guess subnet is ok for him. but +1 for waiting a bit.
14:10:16 <mlavalle> any other opinions?
14:10:56 <mlavalle> ok, then let's wait a bit
14:11:03 <amotoki> I am following the discussion in the bug. It looks okay so far, but one concern is that we spread dns related stuffs across multiple resources (networks, subnets and ports). I try to capture the whole picutre after the meeting
14:11:56 <mlavalle> amotoki: that's all right. if you come up with any thoughts, would you leave a note in the RFE?
14:12:07 <amotoki> mlavalle: sure
14:12:18 <mlavalle> cool
14:12:31 <njohnston> I suppose I would just also note in the bug that we are waiting for more feedback, to see if that spurs comments.  Sorry if that is obvious.
14:12:55 * mlavalle leving a note in RFE
14:12:58 <mlavalle> leaving
14:14:11 <mlavalle> done
14:14:43 <mlavalle> since I see that munimeha1 joined the meeting, let's review his proposal: https://bugs.launchpad.net/neutron/+bug/1794771
14:14:43 <openstack> Launchpad bug 1794771 in neutron "SRIOV trunk port - multiple vlans on same VF" [Wishlist,Triaged]
14:16:23 <slaweq> This one looks fine for me, as long as there is no changes in API it shouldn't be a problem IMO
14:17:40 <munimeha1> yes this is just driver change sending all vlans from subport to driver
14:17:47 <amotoki> yeah, it sounds a request for trunk support in SRIOV case.
14:18:02 <mlavalle> amotoki: yes, that's the way I understand it
14:18:12 <amotoki> I am okay if he doesn't assume any API information including binding:profile.
14:18:54 <amotoki> some vendors tend to use binding:profile as free areas but it should be avoided. we can check it carefully during reviews.
14:19:23 <yamamoto> is this independent from taas sr-iov thing?
14:19:45 <munimeha1> yes this is idependent of that feature
14:20:04 <munimeha1> independent*
14:20:17 <amotoki> not sure in the implementation level, but I think it can be done independently.
14:20:53 <yamamoto> the same party is working on both?
14:21:32 <munimeha1> yes
14:22:35 <yamamoto> and they are for the same hardware?
14:22:45 <munimeha1> yes
14:22:45 <mlavalle> I'm ok moving ahead with RFE
14:22:58 <mlavalle> what do others think?
14:23:04 <slaweq> +1
14:23:10 <amotoki> +1
14:23:55 <haleyb> +1
14:23:58 <manjeets_> +1
14:24:07 <yamamoto> i'm not sure how it interacts with taas part of it. but i guess that kind of details can be discussed on reviews
14:24:10 <yamamoto> so +1
14:24:30 <mlavalle> landslide!
14:24:55 * mlavalle is getting in the  electoral mood in preparation for November
14:25:17 <njohnston> ugh
14:25:26 <manjeets_> lol
14:26:45 <mlavalle> munimeha1: later today I will create a blueprint to track this effort during our weekly meetings
14:27:12 <munimeha1> thanks
14:27:17 <mlavalle> Thanks for your submission, munimeha1
14:27:48 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1789592
14:27:49 <openstack> Launchpad bug 1789592 in neutron "[RFE] Add native OVSDB implementation for OvsdbMonitor" [Wishlist,Triaged]
14:30:28 <njohnston> I am in favor of this, personally
14:31:08 <slaweq> just to be sure, so this will require adding some implementation of ovsdb monitor in ovsdbapp and use it in Neutron later?
14:32:05 <yamamoto> i see no problem with the rfe
14:33:04 <mlavalle> I am also in favor of this RFE
14:33:09 <amotoki> let me ask a question for better understanding. we have ovsdb_interface = native (as default), so what is the missing point?
14:33:50 <slaweq> amotoki: this module: https://github.com/openstack/neutron/blob/master/neutron/agent/common/ovsdb_monitor.py
14:34:12 <slaweq> it's always spawned as subprocess and RFE is about changing it to "native" also
14:34:16 <slaweq> IIUC this rfe
14:34:34 <amotoki> thanks. got it.
14:34:48 <mlavalle> correct, he is referring spifically to that module
14:34:54 <slaweq> I'm fine with this also
14:34:57 <mlavalle> that we "left behind"
14:35:03 <amotoki> I thought it already used the native mode... fine to me now
14:35:37 <mlavalle> any other thoughts?
14:36:33 <mlavalle> ok, I'll mark it as approved since we already have majority
14:37:51 * mlavalle asked bcafarel in the RFE if he plans to implement it
14:38:26 <mlavalle> ok, moving on
14:38:41 <mlavalle> Last one for today is https://bugs.launchpad.net/neutron/+bug/1792901
14:38:41 <openstack> Launchpad bug 1792901 in neutron "[RFE] subnet pool can not delete prefixes" [Wishlist,Triaged]
14:40:37 <mlavalle> I should point out that for this one I pinged tidwellr, who originally helped to implement subnet pools and he has been helping to triage it
14:43:12 <slaweq> about point 2 from Your last comment I think it's fine
14:43:18 <amotoki> I agree with mlavalle's comment in #11. It sounds reasonable to allow to delete a prefix if it is not consumed.
14:43:38 <slaweq> as long as it will check if prefix is not used, we can remove it
14:45:03 <slaweq> about point 1. I don't have much experience with subnetpools so I don't know what consequences may be of such operation
14:45:48 <amotoki> one difficult point as implementation perspective seems how we can change prefix allocations atomicly. it is not an easy thing in SQL level.
14:46:46 <haleyb> agree with allowing, do we think this would need a new extension to support it?
14:46:49 <slaweq> amotoki: but if someone will do it for "onboard" then it should be fine also in the opposite way, right?
14:47:17 <slaweq> haleyb: yes, I think that it will require at least shim extension to make this feature discoverable
14:47:49 <mlavalle> yes, it has to be discoverable
14:48:22 <mlavalle> haleyb: do you know if the openstack client revert on this functionality merged?
14:48:23 <amotoki> slaweq: i think so but not 100% sure...
14:48:31 <haleyb> mlavalle: not yet
14:48:50 <mlavalle> haleyb: should we put it on hold if we approve this rfe?
14:48:56 <bcafarel> not yet, I was waiting for the result of this meeting to see if worthwile to push
14:49:10 <mlavalle> bcafarel: good man. Thanks!
14:50:36 <mlavalle> I am good with moving ahead with this rfe. we can debate the DB atomicity issue in the reviews
14:50:46 <yamamoto> +1
14:50:53 <slaweq> +1
14:51:11 <njohnston> +1
14:51:20 <amotoki> +1
14:51:26 <mlavalle> ok, cool
14:51:30 <slaweq> and also +1 to maybe add this first point to onboarding blueprint
14:51:55 <mlavalle> slaweq: that's a good point. thanks
14:52:24 <mlavalle> I will leave comment in the RFE at the end of the meeting. In the meantime, I want to return 8 minutes to your busy agendas
14:52:29 <mlavalle> Thanks for attending
14:52:38 <mlavalle> have a great weekend!
14:52:43 <mlavalle> #endmeeting