14:00:15 <slaweq> #startmeeting neutron_drivers
14:00:16 <openstack> Meeting started Fri Dec  6 14:00:15 2019 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:16 <slaweq> hi
14:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:20 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:26 <mlavalle> o/
14:01:43 <ralonsoh> hi
14:02:43 <slaweq> lets wait few more minutes to have quorum
14:03:13 <mlavalle> ack
14:03:23 <njohnston> slaweq: I can joino/
14:06:02 <slaweq> amotoki: haleyb yamamoto: drivers meeting, are You around?
14:06:11 <yamamoto> hi
14:07:32 <slaweq> hi yamamoto
14:07:38 <slaweq> so we have quorum now
14:07:46 <slaweq> and we can start
14:07:53 <slaweq> #topic RFEs
14:08:12 <slaweq> first of all I want to talk a bit about https://review.opendev.org/#/c/678865/
14:08:21 <slaweq> RFE for this is already accepted
14:09:00 <slaweq> but proposal from davidsha is to move classifier framework to be in-tree service plugin
14:09:10 <slaweq> we discussed that with amotoki last week
14:09:43 <slaweq> but as today we have more drivers here, I would like to ask again to review this spec and what do You think about moving this service plugin to be in-tree plugin
14:10:04 <mlavalle> I put it yesterday in my pile of reviews
14:10:39 <haleyb> hi, sorry i'm late
14:11:34 <ralonsoh> just to point out: the scope is reduced to QoS and DSCP. In the spec we should also have the DB definition and the API (as Lajos mentioned)
14:11:50 <ralonsoh> but as I commented in QoS meeting and last week here, I'm ok with it
14:12:50 <slaweq> I'm ok with this too if there is no other easy way
14:13:09 <slaweq> but I would like to know others' opinion too
14:13:22 <njohnston> I think it makes far more sense for it to be in-tree
14:13:22 <slaweq> we can discuss that here or in the review of the spec if You want
14:14:43 <slaweq> mlavalle: haleyb yamamoto: so please review this spec soon so we can move forward with this RFE finally :)
14:14:55 <slaweq> would that be good for You?
14:15:11 <mlavalle> as i said above, it is in my pile as of yesterday
14:15:25 <haleyb> i'll put it on my pile as well
14:16:39 <yamamoto> i'll leave the spec open in one of my browser tab so that i will notice it next week
14:17:34 <slaweq> thx
14:17:38 <slaweq> lets move on than
14:17:47 <slaweq> next rfe
14:17:50 <slaweq> https://bugs.launchpad.net/neutron/+bug/1847068
14:17:50 <openstack> Launchpad bug 1847068 in neutron "[RFE] create option in neutron.conf to disable designate+neutron consistency" [Wishlist,New] - Assigned to Gregoire Mahe (gregoiremahe)
14:18:12 <slaweq> we talked about it few times but I want to get back to it once again and agree if we should abandon it or not
14:18:38 <slaweq> I'm for abandoning this rfe as it is trying to solve some very specific to ovh use case
14:20:34 <mlavalle> I am also for not accepting it. I just looked at it and I don't see new info in the RFE. So my position stands
14:20:45 <mlavalle> I'm open to listen to arguments, though
14:22:52 <njohnston> If designate performance is so terrible that neutron needs to treat it with such measures then I think the better solution would be for the requestor to apply effort to fixing the issues they have with designate
14:23:37 <njohnston> I think "let's make into openstack project #1 that it can never trust that project #2 is going to do it's job" is a terrible statement
14:23:42 <njohnston> *bake
14:24:01 <slaweq> njohnston: actually, from my understanding they want to do something like that because they want to use own driver in designate and they want to test that in production without breaking e.g. neutron if something would go wrong
14:24:02 <mlavalle> well, and it is not a Designate problem in general
14:24:44 <njohnston> wait, so once the testing is done they would disable this measure and not use it anymore?
14:24:49 <mlavalle> my employer uses the current Neutron - Designate integration in production every day without a problem
14:25:09 <slaweq> njohnston: idk, but that was my understanding
14:25:31 <mlavalle> this RFE is to address a specific way OVH is deploying Designate
14:27:15 <slaweq> yes, so my vote for this is: -1
14:28:25 <njohnston> -1
14:29:39 <yamamoto> -1
14:29:58 <slaweq> haleyb: any thought?
14:30:11 <haleyb> i would agree, -1
14:30:14 <yamamoto> it seems a temporal solution even for ovh
14:30:38 <mlavalle> slaweq: please tell the OVH folds that I will be available to comment in their code if they want me to
14:30:48 <mlavalle> folks^^^
14:30:48 <slaweq> ok, so we all agreed to -1 it
14:30:51 <slaweq> mlavalle: sure
14:31:08 <slaweq> so I will abandon this rfe with comment why we decided that
14:31:10 <slaweq> thx
14:31:22 <slaweq> next one for today is from ralonsoh
14:31:24 <slaweq> https://bugs.launchpad.net/neutron/+bug/1851362
14:31:24 <openstack> Launchpad bug 1851362 in neutron "[RFE] ports do not inherit their associated network's policy" [Low,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:31:50 <ralonsoh> in a nutshell: in the CLI we are not showing the network QoS policy for a port
14:32:01 <ralonsoh> a port can inherit the network QoS policy
14:32:19 <ralonsoh> and currently the agents are using it, if no port qos policy is defined
14:32:19 <slaweq> so it's only about "cosmetic" change of API, right?
14:32:23 <ralonsoh> exactly
14:32:25 <ralonsoh> only
14:32:36 <ralonsoh> see c#1
14:34:26 <slaweq> Personally I'm ok with such change
14:34:35 <slaweq> ofcourse it has to be discoverable
14:34:50 <slaweq> so new api extension will be needed
14:35:11 <ralonsoh> for sure, see first patch https://review.opendev.org/#/c/693234/
14:35:49 <mlavalle> so, from the Neutron code perspective, is it just a matter of populating the port response with the network's policy id?
14:36:03 <ralonsoh> exactly
14:36:12 <ralonsoh> and then use it in the SDK and the OSclient
14:36:23 <ralonsoh> this parameter will be read-only
14:36:45 <mlavalle> yeap, I see the extension definition in the patch ^^^^
14:37:05 <mlavalle> so yeah, let's do it
14:37:25 <mlavalle> in fact, it might be considered a bug
14:37:28 <slaweq> yamamoto, haleyb: any thoughts about this one?
14:37:45 <slaweq> mlavalle: yes, but as it require api change I wanted to treat it as rfe and discuss here
14:37:48 <mlavalle> because, as the filing of this RFE shows, it confuses users
14:38:11 <mlavalle> cool, let's do it
14:38:15 <ralonsoh> thank you all
14:38:47 <yamamoto> it seems reasonable. i'm not sure it's what the submitter wants to see though.
14:39:21 <ralonsoh> yamamoto, I talked to him and this is the problem: they can't see what's the qos policy on this port
14:39:51 <ralonsoh> (the one in use, in this case, the network one, inherited )
14:39:51 <yamamoto> ralonsoh: ok, then it's fine for me
14:39:55 <haleyb> sorry, got sidetracked, but based on the bug and conversation looks good to me
14:41:50 <slaweq> ok, so I will approve it just after the meeting
14:41:56 <slaweq> as we all agreed with that
14:42:07 <slaweq> ralonsoh: You will implement that, right?
14:42:07 <ralonsoh> thanks
14:42:14 <ralonsoh> I'm on it now
14:42:29 <slaweq> thx
14:42:37 <slaweq> ok, lets move on
14:42:40 <slaweq> next one for today
14:42:43 <slaweq> https://bugs.launchpad.net/neutron/+bug/1851609
14:42:43 <openstack> Launchpad bug 1851609 in neutron "Add an option for graceful l3 agent shutdown" [Medium,In progress] - Assigned to Oleg Bondarev (obondarev)
14:43:03 <slaweq> haleyb: I know You were discussing with Oleg about this
14:44:05 <haleyb> slaweq: yes, i had some questions for him, hopefully didn't confuse him with my container comments
14:45:04 <slaweq> thx haleyb for taking care of it
14:45:10 <haleyb> https://review.opendev.org/#/c/693323/ is the review btw
14:46:17 <slaweq> for me this rfe sounds reasonable for use cases when L3 agent is running in container and in the same container also child processes are running
14:46:22 <haleyb> i don't think my employer needs it, but it could be useful for others perhaps
14:47:12 <slaweq> exactly as haleyb said, it's not the case e.g. in TripleO but for other deployment tools it can be useful
14:48:37 <mlavalle> good discussion in the RFE
14:49:06 <mlavalle> you didn't create confusion haleyb
14:49:42 <haleyb> i just didn't have a good answer for how we did it, some of that stuff is black magic to me
14:51:06 <haleyb> it does solve a problem that can happen in a single-pod neutron deployment
14:51:24 <mlavalle> is there a chance that it is described somewhere in the TripleO docs?
14:52:06 <slaweq> mlavalle: I can ask beagles for that, it's his "baby"
14:52:07 <slaweq> :)
14:53:17 <mlavalle> I don't say reject this RFE for now, but maybe if we reseacrh it a bit, we could find a way to re-use what TripleO did
14:53:51 <mlavalle> maybe it is not that complicated and we save Neutron of another config option
14:54:24 <slaweq> mlavalle: good point, I will ask beagles for details about how it's done in TripleO and we will get back to this discussion next week
14:54:24 <mlavalle> BTW, I am an advocate of Neutron supporting containers as much as possible
14:55:19 <slaweq> are all ok with this plan?
14:55:21 <mlavalle> if you can get beagles to comment in the RFE, it would be good
14:55:44 <haleyb> mlavalle: neutron isn't aware it's happening AUIU, it just spawns things as it always did, but there should be info around to give to Oleg and see what he thinks
14:56:16 <mlavalle> oh yeah
14:56:24 <mlavalle> and that's the way it should be
14:57:07 <mlavalle> my comment above is just meant to say that we in the Neutron team should try to support the growth of Neutron in containers as much as we can
14:57:21 <haleyb> ack
14:58:27 <slaweq> ok, we are almost on top of the hour
14:58:40 <slaweq> so lets ask beagles to comment on this rfe and we will get back to it
14:58:51 <slaweq> thx for attending the meeting and have a great weekend
14:58:53 <slaweq> o/
14:59:08 <mlavalle> cool, have a nice weekend!
14:59:15 <slaweq> #endmeeting