14:00:41 #startmeeting neutron_drivers 14:00:41 Meeting started Fri Feb 25 14:00:41 2022 UTC and is due to finish in 60 minutes. The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:41 The meeting name has been set to 'neutron_drivers' 14:00:43 o/ 14:00:45 o/ 14:00:48 hi 14:00:49 o/ 14:01:07 hi 14:01:10 o/ 14:02:22 o/ 14:02:32 Ok, I think we can start 14:02:36 hi! 14:02:47 Our first RFE: [RFE][L3][OVS] use controller (ovs-agent) send (packet-out) RA to (VMs) ports (#link https://bugs.launchpad.net/neutron/+bug/1961011 ) 14:02:56 this is from liuyulong 14:03:51 to make ovs-agent send out RA packets 14:05:21 is he going to present the RFE? 14:05:37 I think no, but Tuesday he mentioned it: https://meetings.opendev.org/meetings/networking/2022/networking.2022-02-22-14.08.log.html#l-42 14:05:39 I don't see him around 14:06:08 and the information in Launchpad seems pretty concise 14:06:30 yes and the feature is in line with the last ones from liuyulong 14:06:42 this RFE generally makes sense to me, but I wonder what is the severity of the impact of https://review.opendev.org/c/openstack/neutron/+/707406 14:07:01 the proposal proposes "Revert https://review.opendev.org/c/openstack/neutron/+/707406 and always keep qg- interfaces up" as the first step. 14:07:15 my concern with this is mostly related to the "design" of our agents - our neutron-ovs-agent is slowly getting to be "all-in-one-agent" 14:07:31 but I know we already did things like e.g. dhcp in it so... 14:08:24 slaweq: that's true, and ovs-agent is not an easy to understand/debug module 14:08:53 it also has own performance/scalability problems already 14:09:17 woops,,, sorry. I opened a different tab in a browse. 14:09:24 please ignore my comment 14:09:38 maybe it can be done as agent extension 14:09:41 is this RFE going to be configurable? 14:09:44 amotoki: no problem 14:09:50 slaweq answered that 14:09:51 then it could be enabled if needed only 14:10:00 +1 to this 14:10:02 I think if this is an optional feature it's not that bit problem 14:10:26 yeah, the agent extension approach addresses the debuggability / understability issue. Not the potential performance issue, though 14:10:27 agree, +1 14:11:28 agent extension worked for the distributed dhcp also, so we can keep this aproach 14:11:30 (now I recall, the DHCP feature should have been an extension too) 14:11:50 DHCP feature is not an extension 14:11:59 the code in implemented directly on the agent 14:12:02 as an optional deployment approach, with the appropriate caveats in the documentation about performance impact in the L2 agent, might be ok 14:12:23 with an extension approach 14:12:34 ralonsoh yeah, and that's mistake, it should be an extension too 14:13:03 mlavalle I know that it won't address performance problems but at least by default users will not have it enabled :) 14:13:20 I would +1 this RFE commenting that this should be implemented as an OVS agent extension 14:13:45 yes, that's what I'm saying. Let's give operators the option and warn them of the potential performance problem 14:14:06 I'm also not saying that this specific thing will dramatically lower performance of the agent, but that it's another thing which we want to add to the same agent which is single thread always, and at some point it may be too much simply :) 14:14:22 agree 14:14:24 you are right on this 14:14:46 (we have seen this problem frecuently in beefy compute nodes with 100s of VMs) 14:14:54 ++ 14:15:17 hehe, I saw it too 14:15:20 hi, sorry for being late 14:15:39 obondarev, https://bugs.launchpad.net/neutron/+bug/1961011 14:15:43 this is the topic now 14:16:08 got it, makes sense for me 14:16:08 ok, so I add the notes to the RFE to implement it as an agent extension 14:16:24 +1 14:16:49 +1 14:16:56 +1 from me 14:17:02 +1 14:17:23 yeah, like recent one for dhcp extension 14:17:26 +1 from me too 14:17:57 ok, thanks, than accepted 14:18:10 Next one: [RFE][OVN] Support DNS subdomains at a network level (#link https://bugs.launchpad.net/neutron/+bug/1960850 ) 14:18:25 elvira2, ^ 14:19:14 sorry, +1 from me to the previous one if it will be an extension :) 14:20:11 elvira2, how will you pass this subdomain name? what kind of API do you propose? 14:20:33 will it be a parity gap with OVS? 14:21:11 I wonder what kind of changes we need in the API side to support this RFE. 14:21:39 it is already what I think ralonsoh pointed. 14:21:41 I can answer these questions 14:21:57 I helped elvira2 putting together the RFE 14:22:54 1) No changes to the API. what is being proposed is just to apply the current dns_domain attribute in networks and apply it to the OVN DHCP record of the corresponding port 14:23:18 hi, thanks ralonsoh, bad connection today. I was thinking of setting this with a config option and getting the name from the subnet name into the OVN database, I have not thought yet about how to code it exactly 14:23:47 but as mlavalle said, it should not require api changes as far as I'm concerned 14:23:58 how a LS dns_domain is set? 14:24:13 so it's OVN only option? 14:24:20 2) It is not intended to get feature parity with OVS in the sense of integrating with Designate. It is just a way to allow users to come up with more flexible FQDN's for their instances 14:24:37 ralonsoh: what is LS? 14:24:45 Logical Switch 14:24:45 mlavalle didn't we made something like that in the past and later reverted it? 14:24:51 OVN logical_swithc 14:24:55 (a network in OVN) 14:25:40 (ah.. thanks... i always use the full spelling :p) 14:26:07 ralonsoh: for each port in the OVN northbound DB there is a DHCP recors 14:26:17 record 14:26:37 Bogdan Dobrelya proposed openstack/neutron master: Log request IDs for matched Nova external events https://review.opendev.org/c/openstack/neutron/+/828687 14:27:01 the RFE proposes to take dns_domain of the neutron network and apply it to the DHCP record of the OVN port 14:27:39 not for each port, but for each subnet 14:27:44 today, we populate that DHCP record with the dns_domain from neutron.conf 14:27:50 there is a dhcp_options record per subnet 14:28:40 is there any difference from the perspective of VMs (neutron port consumers)? or no difference from VM? 14:29:50 Bogdan Dobrelya proposed openstack/neutron master: Log request IDs for matched Nova external events https://review.opendev.org/c/openstack/neutron/+/828687 14:30:10 hang on a bit. I documented this a bit. Let me find it 14:32:06 this is how we implement this dhcp options in ml2 / ovn: https://docs.openstack.org/neutron/latest/contributor/internals/ovn/native_dhcp.html 14:33:50 but the underlying north bound DB has a dhcp record at the port level 14:35:19 Indeed. I believe that as long as the vm gets the fqdn from the port it should be ok. But I would need to learn a bit more about how Nova manages that exactly 14:35:43 please look here: https://paste.openstack.org/show/b2tfxZWOm3jbgJfkFlSo/ 14:36:23 mlavalle, the dhc_options register is per subnet, not per port 14:36:44 mlavalle I think You missed my question earlier, is this proposal about doing something what was already reported as mistake in https://bugs.launchpad.net/neutron/+bug/1826419 and then reverted? 14:36:46 ralonsoh: yes, in ML2 ovn 14:36:54 or am I missunderstanding it? 14:37:05 slaweq: I'll get back to that in a minute 14:37:16 ok, thx a lot 14:37:39 ralonsoh: but the underlying ovn db has it at the port level 14:37:44 perfect 14:37:49 ralonsoh: please look at https://paste.openstack.org/show/b2tfxZWOm3jbgJfkFlSo/ 14:38:51 so in a nutshell, with this new extension, you'll be able to have a single dhcp register per port, adding the port.dns_name there 14:38:54 right? 14:39:38 ralonsoh: correct. That will enable ml2 / ovn users to have a more flexible way to name their VMs 14:39:43 AFAIU this will be new config option, not extension, is that correct? 14:39:45 understood 14:39:57 as opposed to all the VMs in a flat domain defined in neutron.conf 14:40:19 right, this should be configurable 14:40:28 yes, obondarev 14:40:33 correct 14:40:35 ack, thanks 14:41:04 in fact, if we decide so, we might give the users to use the dns_domain from the network or from the port 14:41:32 inherit from the "farther", as in qos policies 14:41:40 s/"father" 14:41:53 no we have have the dns_integgration extension 14:42:12 where ports use the dns_domain from their network 14:42:33 but we also have the dns_integration_port extension, where a port can have its own dns_domain 14:43:00 maybe that's not the name of the extension, but you get the idea 14:44:28 now, going back to slaweq, yes, in 2019 we changed that. But the in the Victoria cycle, we approved and implemented https://specs.openstack.org/openstack//neutron-specs/specs/victoria/port_dns_assignment.html 14:44:28 malavalle: dns-domain-ports (https://opendev.org/openstack/neutron-lib/src/branch/master/neutron_lib/api/definitions/dns_domain_ports.py ) 14:44:45 lajoskatona: thanks, that's the one 14:45:20 so in essence, in OVS with DNS integartion we are doing what we are proposing for OVN 14:45:43 does that answer your question slaweq? 14:46:48 mlavalle I remember now, the one thing I'm still confused with is that RFE https://specs.openstack.org/openstack//neutron-specs/specs/victoria/port_dns_assignment.html was about integration with designate (external DNS let's say), and dns_domain in the config option is about configuration in dnsmasq (internal DNS let's say). Is that correct? 14:47:17 it is correct 14:47:29 and if it is right, then bug https://bugs.launchpad.net/neutron/+bug/1826419 was also about this "internal DNS" that it shouldn't use dns_domain from the network/port as those were for designate, not for dnsmasq 14:48:01 so if we are going to accept elvira's rfe now, we may have again opened https://bugs.launchpad.net/neutron/+bug/1826419 - is that correct? 14:48:13 yes, but we don't have that legacy in the OVN case 14:48:19 sorry, but I'm always very confused with all those dns settings in Neutron :) 14:48:48 ml2 ovn is anyway doing its own thing with DHCp 14:49:20 which is https://docs.openstack.org/neutron/latest/contributor/internals/ovn/native_dhcp.html 14:49:34 so do You propose to do things with network's/port's dns_domain attribute differently than in ML2/OVS case? 14:49:56 if I understand well that bug is related to how we use dnsmasq, but as OVN has it's own impelmentation for dhcp and dns we can avoid that 14:50:00 we are proposing extending the behavior documented in https://docs.openstack.org/neutron/latest/contributor/internals/ovn/native_dhcp.html 14:50:19 to be more flexible 14:50:49 leveraging the dns_domain attribute that already exists in the API for networks and ports 14:51:01 that's it 14:52:00 that's the moment to properly document this feature, if implemented, in both backends 14:52:06 I don't think I can fully capture the whole context discussed in the meeting... I think we need to clarify what is compatible with ml2/ovs and what is different (or new) in ml2/ovn. the bug pointed by slaweq is a good example. 14:52:27 *by this proposal 14:52:28 OVN+this feature == OVS + designate 14:52:34 this is the summary 14:52:36 maybe I'm still missing something there (sorry for that) but, if I will not look at the backend implementation (ovn vs dnsmasq) but only api side, You want to do exactly the same thing as was done in https://bugs.launchpad.net/neutron/+bug/1774710 and later reverted as per https://bugs.launchpad.net/neutron/+bug/1826419 14:52:49 amotoki: agree, we need clear documentation 14:53:20 slaweq: yes, for ml2 / OVN 14:53:21 I'm not against it, just want to understand if this is correct and if so, maybe we will need to announce that change loud and document it properly to avoid another reverts in the future 14:53:37 since ml2 / ovn does it's own thing anyway 14:53:49 regarding DHCP 14:54:04 mlavalle but then You propose to have different API behavior depending on the backend used, right 14:54:05 ? 14:54:34 that's the way it is today 14:55:24 we are just proposing making the OVN case more flexible 14:56:07 yes. This behaviour change should only be noticed if the configuration is explicitly changed and not by default, I think 14:56:59 the point is that those dns extension are intended to work with OVS designate now 14:57:08 TBH I'm not against it but for me it is confusing already and will be even more confusing probably :) 14:57:14 if you use OVS without designate, you won't have this functionality 14:57:30 OVS currently does not implement those features 14:57:34 ralonsoh: correct 14:57:36 but will do natively 14:57:45 so 14:57:49 OVN+this feature == OVS + designate 14:57:50 ralonsoh so dns_domain attribute in port/network is added only by the dns-integration extension? Is that correct? 14:57:58 ok 14:58:00 yes 14:58:07 slaweq: yes 14:58:16 designate is for global DNS, OVN will only answer internally, not? 14:58:27 frickler: correct 14:58:32 but we'll really need very good document about that :) 14:58:36 that's what it does today 14:58:38 so the aboe == is wrong 14:58:38 slaweq, for sure 14:59:01 to explain once and forever what attribute or config option is when available and when responsible for what exactly 14:59:10 frickler, please, explain that 14:59:10 I think I at least understood it now 14:59:21 sorry for asking so many questions there :) 14:59:32 slaweq: that's what we are here for 14:59:36 I have to leave now, I had to speak on talk that is scheduled in 2 minutes. Thanks a lot for caring about the RFE and I will read the rest of the discussion later! See you around 14:59:39 slaweq: that's the way we all learn new things 14:59:46 Our time is up 14:59:49 anyway 14:59:52 slaweq: thanks for your questions 14:59:55 with designate, you create records that can be resolved from anywhere, with OVN you get records faked only for queries inside a tenant network 15:00:22 frickler, and this will be documented 15:00:26 but with this limit 15:00:29 the == is correct 15:00:45 and that was just to make the goal of this feature more clear 15:00:46 I think this RFE need a spec to have it all written 15:01:08 +1 for spec 15:01:45 +1 for spec. I am not against the idea but I agree more clarification is required :) 15:01:50 +1 15:02:14 +1 for the idea, and for more discussion in spec 15:02:33 +1 15:02:57 ok, will write a spec. Thanks 15:03:26 mlavalle, elvira2: thanks for the proposal 15:03:32 really intersting discussion. neutron designate integration and dns support are really not easy to understand to capture the full context.... 15:03:57 ok, I will update the RFE, with the comments 15:04:36 damiandabrowski[m]: sorry we had long discussion, we have to discuss another time your issue with gARP 15:04:52 #endmeeting