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