14:00:17 <mlavalle> #startmeeting neutron_drivers
14:00:18 <openstack> Meeting started Fri Aug  2 14:00:17 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:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:21 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:59 <njohnston> o/
14:01:54 <amotoki> hi
14:02:26 <ralonsoh> hi
14:02:50 <slaweq> hi
14:02:55 <slaweq> sorry for being late
14:03:15 <mlavalle> let's wait one more minute
14:05:12 <mlavalle> we have quorum, so let's get going
14:05:12 <davidsha> o/
14:05:19 <mlavalle> #topic RFEs
14:05:43 <mlavalle> Last week we concluded the meeting having said we were going to look at https://bugs.launchpad.net/neutron/+bug/1817881
14:05:44 <openstack> Launchpad bug 1817881 in neutron " [RFE] L3 IPs monitor/metering via current QoS functionality (tc filters)" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889)
14:05:57 <haleyb> hi
14:06:19 <mlavalle> and more specifically, we were going to review the spec: https://review.opendev.org/#/c/658511/
14:06:29 <mlavalle> which we did :-)
14:06:37 <mlavalle> Thanks
14:08:46 <mlavalle> In m,y review of the spec, I am mostly ok with it and the RFE
14:09:15 <amotoki> what I still haven't understood well is whether it requires the API change or not.
14:09:42 <mlavalle> I think the last remaining sticking point is to require the deployer to enable the QoS extension to enable the proposed new extension
14:10:03 <slaweq> My only concern is to not bind it with QoS from user perspective at all - those are 2 completly different functionalities IMO
14:10:22 <mlavalle> yeap, we agree on that slaweq
14:10:25 <amotoki> slaweq: +1
14:10:29 <slaweq> thx
14:11:00 <yamamoto> hi
14:11:02 <yamamoto> sorry late
14:11:08 <slaweq> amotoki: about API, my understanding is that any changes aren't needed really
14:11:19 <mlavalle> amotoki: it doesn't look to me that an API change is required, but we can ask in the spec or the RFE to make sure
14:11:25 <slaweq> amotoki: IIUC spec, it will be new l3_agent extension which can be loaded on L3 agent's config file
14:11:53 <slaweq> and than L3 agent will set those counters and sent this data periodically to some external "collector"
14:12:12 <amotoki> thanks for the feedback. +1 to clarify whether it needs the REST API change or not in the spec.
14:12:30 <amotoki> I am fine to use the same mechanism for QoS and metering. It sounds natural.
14:12:33 <slaweq> +1 that this should be clearly written there
14:13:38 <slaweq> amotoki: I'm fine to use same mechanism underneath (tc and its counters) but I don't think it should work like: if You want to have metering on FIP, please attach QoS with bw limit to it
14:14:26 <mlavalle> most likely all agree on that.... let's see what haleyb and yamamoto say
14:14:27 <amotoki> slaweq: that's the same concern I have from past discussions.
14:15:06 <haleyb> mlavalle: i just read the spec, and would agree with slaweq and amotoki
14:15:29 <yamamoto> i agree
14:15:53 <mlavalle> I see liuyulong just joined the meeting....
14:16:34 <liuyulong> hhi
14:16:42 <slaweq> hi liuyulong
14:16:49 <mlavalle> liuyulong: we are discussing your metering proposal
14:16:56 <liuyulong> I hit some traffic...
14:17:02 <liuyulong> OK
14:17:03 <mlavalle> in summary, we have two questions
14:17:28 <mlavalle> 1) Are API changes required by this RFE / spec?
14:18:30 <liuyulong> No, for the SPEC now, it is only a new L3 agent extension.
14:18:56 <mlavalle> cool, let's make that explicit in the spec
14:19:13 <amotoki> liuyulong: does this mean the metering feature can be used without QoS rule?
14:19:21 <amotoki> my question is just for clarification
14:19:39 <mlavalle> 2) We all agree that from the point of view of the operator, QoS extension shouldn't be required
14:20:22 <liuyulong> Router gateway IP QoS and Floating IP QoS will be needed. That means L3 agent fip_qos and gateway_ip_qos agent extension will be required.
14:20:37 <liuyulong> https://review.opendev.org/#/c/658511/5/specs/train/l3-ips-metering.rst@147
14:20:45 <liuyulong> I added the Dependencies here ^^
14:21:11 <amotoki> liuyulong: could you distinguish "REST API extension" and "L3 agent extension"?
14:21:35 <mlavalle> but why not have a config option that enables this new extension and then installs the required TC rules on those IPs
14:21:54 <slaweq> liuyulong: but why You require FIP and GW QoS to be enabled to use metering?
14:22:09 <liuyulong> amotoki, it is L3 agent extension.
14:22:31 <liuyulong> mlavalle, then we will implement the TC installing and caching once again?
14:22:53 <mlavalle> no, you reuse the same code as much as possible
14:22:58 <liuyulong> we can directly use the installed TC filter rules.
14:23:06 <slaweq> mlavalle +1
14:23:08 <mlavalle> just have different ways to enable it
14:23:46 <amotoki> can we use the proposed metering feature without *new procedure* from the perspective of REST API?
14:23:47 <amotoki> I haven't got we are okay to use the same mechanism for both qos and metering.
14:24:00 <amotoki> perhaps I am asking the same thing for clarification
14:24:31 <amotoki> sorry.. s/I haven't//
14:24:31 <liuyulong> slaweq, mlavalle, what's the default value should be?
14:24:51 <mlavalle> default value for what?
14:25:08 <liuyulong> TC filter
14:25:21 <mlavalle> default value is no tc filter
14:25:54 <mlavalle> tc filter will be put in place if either QoS or the new extension are enabled through config options
14:25:57 <mlavalle> or both
14:27:18 <slaweq> liuyulong: do You need filter with bw limit always? won't it work without limits? Like e.g. filter to match all traffic to/from FIP?
14:27:21 <liuyulong> TC filters without rate or burst value?
14:27:36 <slaweq> (sorry, I don't remember exactly how this works in tc)
14:28:14 <ralonsoh> yes, you can write a filter passing all traffic without BW limits
14:28:35 <slaweq> ralonsoh: thx
14:28:47 <slaweq> so, maybe it could work like that:
14:28:59 <liuyulong> amotoki, for the SPEC now, we will not introduce new API. server side is as usual.
14:29:04 <slaweq> if there is no QoS for FIP, set rule without bw limits
14:29:12 <liuyulong> OK, looks good
14:29:16 <slaweq> if then qos is set for fip, override this filter with qos ones
14:29:21 <liuyulong> I may test this.
14:30:01 <liuyulong> Only match the U32 classifier, but no traffic policing.
14:30:20 <slaweq> liuyulong: exactly
14:31:21 <amotoki> liuyulong: that would be fine. we all seem okay to use TC filters for metering. what we concern is just whether the new metering requires QoS rules.
14:31:47 <mlavalle> ok, based on this understanding, I propose that we approve the RFE, clarifying both in the RFE and the spec how the TC filters will be handled
14:31:54 <mlavalle> ok with everybody?
14:32:28 <slaweq> ++
14:32:30 <liuyulong> amotoki, it will, if user enable floating IP QoS and gateway IP QoS. But if not enable such qos_* extension, then such filter without  traffic policing will not involve the QoS rules.
14:32:33 <haleyb> +1
14:33:13 <liuyulong> I need to test the last proposal.
14:33:42 <amotoki> liuyulong: do you mean we can use the metering feature without QoS feature?f
14:34:11 <liuyulong> amotoki, Yes (but not tested yet)
14:34:39 <mlavalle> liuyulong: can report the results of his testing in the spec
14:34:44 <amotoki> liuyulong: fine. we don't want you to test it now :)
14:35:04 <liuyulong> Sure
14:35:15 <mlavalle> for today, I propose we approve the RFE, ok?
14:35:19 <amotoki> +1 to mlavalle's proposal. I am okay to approve the RFE and let's cover the detail in the spec.
14:36:23 <slaweq> +1
14:38:30 <mlavalle> you ok, yamamoto?
14:38:33 <yamamoto> +1
14:38:37 <mlavalle> cool
14:38:43 <mlavalle> approved it is
14:39:10 <liuyulong> Thank you, I will update the info as soon as possible.
14:39:28 <amotoki> liuyulong: thanks for your effort!!
14:39:52 <mlavalle> liuyulong: thanks for your proposal and hard work!
14:40:22 <mlavalle> Next one for today comes from "El Comandante" himself: https://bugs.launchpad.net/neutron/+bug/1838621
14:40:23 <openstack> Launchpad bug 1838621 in neutron "[RFE] Configure extra dhcp options via API and per network" [Wishlist,Triaged] - Assigned to Slawek Kaplonski (slaweq)
14:40:40 <slaweq> LOL
14:42:15 <slaweq> I had similar request from customer this week, and I thought that this could be set via API for network, in similar way how e.g. mtu is now possible to set
14:42:18 <mlavalle> it is a nickname that his co-workers gave him in his previous job
14:42:25 <slaweq> mlavalle: yes
14:42:34 <mlavalle> they even gave him a t-shirt
14:42:50 <slaweq> mlavalle: no, my wife bought me this t-shirt :)
14:43:07 <mlavalle> ahhhh, it is sacred then
14:43:40 <slaweq> yes :)
14:44:24 <njohnston> LOL
14:44:42 <haleyb> slaweq: are the options just a string?  or ??  just wondering how we validate as to not break dnsmasq
14:45:04 <mlavalle> good question
14:45:31 <slaweq> yes, options are just strings
14:46:05 <slaweq> I wanted to allow just to put in this new attribute options in same format as it can be done now in /etc/neutron/dnsmasq.conf file
14:46:28 <amotoki> apart from LOL, the API level configuration sounds reasonable as dhcp options do not depend on the impl like dnsmasq.
14:46:46 <mlavalle> +1
14:47:02 <njohnston> +1
14:47:30 <amotoki> while we need to choose reasonable acceptable DHCP options, the proposal makes sense to me
14:48:15 <slaweq> amotoki: we can add some validation of what is given through API and only allow to set there reasonable options
14:48:15 <yamamoto> i don't know how dnsmasq config format looks like. is it good enough to have as a part of our api as it is?
14:48:45 <amotoki> slaweq: yeah, totally agree
14:49:08 <haleyb> right, i'm just remembering dnsmasq being "weird" by having things like "option42" or something like that
14:49:36 <amotoki> haleyb: +1
14:49:58 <slaweq> yamamoto: it is jus string like "dhcp-option=3,1.2.3.4" and there can be many such options added to this file
14:49:59 <haleyb> it would be good if it was generic enough to support more than dnsmasq, like OVN dhcp :)
14:50:17 <amotoki> slaweq: one more question. DHCP options are specific to a subnet in general. is it "per network"?
14:50:43 <slaweq> amotoki: dnsmasq server is spawned "per network" by dhcp-agent
14:50:54 <slaweq> so I was thinking about making it "per network"
14:51:12 <slaweq> haleyb: I agree, it should be generic
14:51:28 <amotoki> ah... it is a tricky side. I need to check more detail.
14:51:42 <slaweq> I can check how it would be in case of ovn
14:52:44 <mlavalle> can you do that checking by next week's meeting? and we ra-take this RFE as the first topic next Friday?
14:52:46 <amotoki> but this proposal makes sense to me from the point of that we can provide a way to configure dhcp options not specific to dnsmasq.
14:53:11 <slaweq> mlavalle: me or amotoki?
14:53:18 <mlavalle> slaweq: you
14:53:37 <haleyb> slaweq: amotoki's question about subnets was interesting, as things like host routes provided by dhcp are there, would any of these options be specific to a subnet?
14:53:57 <slaweq> mlavalle: sure, I will check that and update comments in LP
14:54:47 <mlavalle> ok
14:54:56 <amotoki> another important thing I would like to note on the current extra-dhcp-opts is that our  current API on extra-dhcp-opts is tricky and its behavior is different from the usual REST API behavior....
14:55:30 <amotoki> it might be a chance to explore the REST-compliant behavior on this.
14:56:06 <mlavalle> can you elaborate amotoki?
14:56:42 <mlavalle> either here or in the RFE (mlavalle looking at the watch)
14:56:43 <amotoki> for example, if we drop some dhcp-opts we need to specify dhcp-opt name only (without a value).
14:57:18 <amotoki> it is a separate topic and I can explain it in a bug (or somewhere)
14:57:40 <slaweq> ok, I wasn't aware of this extension and possibility to set such options "per port"
14:57:50 <slaweq> I will need to explore it more than
14:58:16 <mlavalle> cool, please comment your findings in the RFE
14:58:23 <slaweq> mlavalle: sure, I will
14:58:29 <mlavalle> ok
14:58:33 <yamamoto> a consistent weird behaviour might be better than two different behaviours
14:58:50 <mlavalle> LOL, that may be true
14:58:57 <amotoki> :p
14:59:12 <mlavalle> Ok, thanks for attending
14:59:30 <mlavalle> have a great weekend
14:59:37 <slaweq> thx and have a great weekend :)
14:59:38 <mlavalle> #endmeeting