14:00:41 <lajoskatona> #startmeeting neutron_drivers
14:00:41 <opendevmeet> 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 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:41 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:00:43 <mlavalle> o/
14:00:45 <lajoskatona> o/
14:00:48 <slaweq> hi
14:00:49 <amotoki> o/
14:01:07 <ralonsoh> hi
14:01:10 <trident> o/
14:02:22 <rubasov> o/
14:02:32 <lajoskatona> Ok, I think we can start
14:02:36 <damiandabrowski[m]> hi!
14:02:47 <lajoskatona> 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 <lajoskatona> this is from liuyulong
14:03:51 <lajoskatona> to make ovs-agent send out RA packets
14:05:21 <ralonsoh> is he going to present the RFE?
14:05:37 <lajoskatona> 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 <mlavalle> I don't see him around
14:06:08 <mlavalle> and the information in Launchpad seems pretty concise
14:06:30 <lajoskatona> yes and the feature is in line with the last ones from liuyulong
14:06:42 <amotoki> 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 <amotoki> 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 <slaweq> 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 <slaweq> but I know we already did things like e.g. dhcp in it so...
14:08:24 <lajoskatona> slaweq: that's true, and ovs-agent is not an easy to understand/debug module
14:08:53 <slaweq> it also has own performance/scalability problems already
14:09:17 <amotoki> woops,,, sorry. I opened a different tab in a browse.
14:09:24 <amotoki> please ignore my comment
14:09:38 <slaweq> maybe it can be done as agent extension
14:09:41 <ralonsoh> is this RFE going to be configurable?
14:09:44 <lajoskatona> amotoki: no problem
14:09:50 <ralonsoh> slaweq answered that
14:09:51 <slaweq> then it could be enabled if needed only
14:10:00 <ralonsoh> +1 to this
14:10:02 <lajoskatona> I think if this is an optional feature it's not that bit problem
14:10:26 <mlavalle> yeah, the agent extension approach addresses the debuggability / understability issue. Not the potential performance issue, though
14:10:27 <lajoskatona> agree, +1
14:11:28 <lajoskatona> agent extension worked for the distributed dhcp also, so we can keep this aproach
14:11:30 <ralonsoh> (now I recall, the DHCP feature should have been an extension too)
14:11:50 <ralonsoh> DHCP feature is not an extension
14:11:59 <ralonsoh> the code in implemented directly on the agent
14:12:02 <mlavalle> 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 <mlavalle> with an extension approach
14:12:34 <slaweq> ralonsoh yeah, and that's mistake, it should be an extension too
14:13:03 <slaweq> mlavalle I know that it won't address performance problems but at least by default users will not have it enabled :)
14:13:20 <ralonsoh> I would +1 this RFE commenting that this should be implemented as an OVS agent extension
14:13:45 <mlavalle> yes, that's what I'm saying. Let's give operators the option and warn them of the potential performance problem
14:14:06 <slaweq> 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 <mlavalle> agree
14:14:24 <ralonsoh> you are right on this
14:14:46 <ralonsoh> (we have seen this problem frecuently in beefy compute nodes with 100s of VMs)
14:14:54 <slaweq> ++
14:15:17 <amotoki> hehe, I saw it too
14:15:20 <obondarev> hi, sorry for being late
14:15:39 <ralonsoh> obondarev, https://bugs.launchpad.net/neutron/+bug/1961011
14:15:43 <ralonsoh> this is the topic now
14:16:08 <obondarev> got it, makes sense for me
14:16:08 <lajoskatona> ok, so I add the notes to the RFE to implement it as an agent extension
14:16:24 <ralonsoh> +1
14:16:49 <mlavalle> +1
14:16:56 <haleyb> +1 from me
14:17:02 <lajoskatona> +1
14:17:23 <obondarev> yeah, like recent one for dhcp extension
14:17:26 <amotoki> +1 from me too
14:17:57 <lajoskatona> ok, thanks, than accepted
14:18:10 <lajoskatona> Next one: [RFE][OVN] Support DNS subdomains at a network level (#link https://bugs.launchpad.net/neutron/+bug/1960850 )
14:18:25 <ralonsoh> elvira2, ^
14:19:14 <slaweq> sorry, +1 from me to the previous one if it will be an extension :)
14:20:11 <ralonsoh> elvira2, how will you pass this subdomain name? what kind of API do you propose?
14:20:33 <ralonsoh> will it be a parity gap with OVS?
14:21:11 <amotoki> I wonder what kind of changes we need in the API side to support this RFE.
14:21:39 <amotoki> it is already what I think ralonsoh pointed.
14:21:41 <mlavalle> I can answer these questions
14:21:57 <mlavalle> I helped elvira2 putting together the RFE
14:22:54 <mlavalle> 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 <elvira2> 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 <elvira2> but as mlavalle said, it should not require api changes as far as I'm concerned
14:23:58 <ralonsoh> how a LS dns_domain is set?
14:24:13 <obondarev> so it's OVN only option?
14:24:20 <mlavalle> 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 <amotoki> ralonsoh: what is LS?
14:24:45 <mlavalle> Logical Switch
14:24:45 <slaweq> mlavalle didn't we made something like that in the past and later reverted it?
14:24:51 <ralonsoh> OVN logical_swithc
14:24:55 <ralonsoh> (a network in OVN)
14:25:40 <amotoki> (ah.. thanks... i always use the full spelling :p)
14:26:07 <mlavalle> ralonsoh: for each port in the OVN northbound DB there is a DHCP recors
14:26:17 <mlavalle> record
14:26:37 <opendevreview> 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 <mlavalle> 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 <ralonsoh> not for each port, but for each subnet
14:27:44 <mlavalle> today, we populate that DHCP record with the dns_domain from neutron.conf
14:27:50 <ralonsoh> there is a dhcp_options record per subnet
14:28:40 <amotoki> is there any difference from the perspective of VMs (neutron port consumers)? or no difference from VM?
14:29:50 <opendevreview> 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 <mlavalle> hang on a bit. I documented this a bit. Let me find it
14:32:06 <mlavalle> 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 <mlavalle> but the underlying north bound DB has a dhcp record at the port level
14:35:19 <elvira> 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 <mlavalle> please look here: https://paste.openstack.org/show/b2tfxZWOm3jbgJfkFlSo/
14:36:23 <ralonsoh> mlavalle, the dhc_options register is per subnet, not per port
14:36:44 <slaweq> 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 <mlavalle> ralonsoh: yes, in ML2 ovn
14:36:54 <slaweq> or am I missunderstanding it?
14:37:05 <mlavalle> slaweq: I'll get back to that in a minute
14:37:16 <slaweq> ok, thx a lot
14:37:39 <mlavalle> ralonsoh: but the underlying ovn db has it at the port level
14:37:44 <ralonsoh> perfect
14:37:49 <mlavalle> ralonsoh: please look at https://paste.openstack.org/show/b2tfxZWOm3jbgJfkFlSo/
14:38:51 <ralonsoh> 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 <ralonsoh> right?
14:39:38 <mlavalle> ralonsoh: correct. That will enable ml2 / ovn users to have a more flexible way to name their VMs
14:39:43 <obondarev> AFAIU this will be new config option, not extension, is that correct?
14:39:45 <ralonsoh> understood
14:39:57 <mlavalle> as opposed to all the VMs in a flat domain defined in neutron.conf
14:40:19 <ralonsoh> right, this should be configurable
14:40:28 <elvira> yes, obondarev
14:40:33 <mlavalle> correct
14:40:35 <obondarev> ack, thanks
14:41:04 <mlavalle> 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 <ralonsoh> inherit from the "farther", as in qos policies
14:41:40 <ralonsoh> s/"father"
14:41:53 <mlavalle> no we have have the dns_integgration extension
14:42:12 <mlavalle> where ports use the dns_domain from their network
14:42:33 <mlavalle> but we also have the dns_integration_port extension, where a port can have its own dns_domain
14:43:00 <mlavalle> maybe that's not the name of the extension, but you get the idea
14:44:28 <mlavalle> 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 <lajoskatona> malavalle:  dns-domain-ports (https://opendev.org/openstack/neutron-lib/src/branch/master/neutron_lib/api/definitions/dns_domain_ports.py )
14:44:45 <mlavalle> lajoskatona: thanks, that's the one
14:45:20 <mlavalle> so in essence, in OVS with DNS integartion we are doing what we are proposing for OVN
14:45:43 <mlavalle> does that answer your question slaweq?
14:46:48 <slaweq> 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 <mlavalle> it is correct
14:47:29 <slaweq> 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 <slaweq> 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 <mlavalle> yes, but we don't have that legacy in the OVN case
14:48:19 <slaweq> sorry, but I'm always very confused with all those dns settings in Neutron :)
14:48:48 <mlavalle> ml2 ovn is anyway doing its own thing with DHCp
14:49:20 <mlavalle> which is https://docs.openstack.org/neutron/latest/contributor/internals/ovn/native_dhcp.html
14:49:34 <slaweq> so do You propose to do things with network's/port's dns_domain attribute differently than in ML2/OVS case?
14:49:56 <lajoskatona> 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 <mlavalle> we are proposing extending the behavior documented in https://docs.openstack.org/neutron/latest/contributor/internals/ovn/native_dhcp.html
14:50:19 <mlavalle> to be more flexible
14:50:49 <mlavalle> leveraging the dns_domain attribute that already exists in the API for networks and ports
14:51:01 <mlavalle> that's it
14:52:00 <ralonsoh> that's the moment to properly document this feature, if implemented, in both backends
14:52:06 <amotoki> 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 <amotoki> *by this proposal
14:52:28 <ralonsoh> OVN+this feature  == OVS + designate
14:52:34 <ralonsoh> this is the summary
14:52:36 <slaweq> 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 <lajoskatona> amotoki: agree, we need clear documentation
14:53:20 <mlavalle> slaweq: yes, for ml2 / OVN
14:53:21 <slaweq> 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 <mlavalle> since ml2 / ovn does it's own thing anyway
14:53:49 <mlavalle> regarding DHCP
14:54:04 <slaweq> mlavalle but then You propose to have different API behavior depending on the backend used, right
14:54:05 <slaweq> ?
14:54:34 <mlavalle> that's the way it is today
14:55:24 <mlavalle> we are just proposing making the OVN case more flexible
14:56:07 <elvira> yes. This behaviour change should only be noticed if the configuration is explicitly changed and not by default, I think
14:56:59 <ralonsoh> the point is that those dns extension are intended to work with OVS designate now
14:57:08 <slaweq> TBH I'm not against it but for me it is confusing already and will be even more confusing probably :)
14:57:14 <ralonsoh> if you use OVS without designate, you won't have this functionality
14:57:30 <ralonsoh> OVS currently does not implement those features
14:57:34 <mlavalle> ralonsoh: correct
14:57:36 <ralonsoh> but will do natively
14:57:45 <ralonsoh> so
14:57:49 <ralonsoh> OVN+this feature  == OVS + designate
14:57:50 <slaweq> ralonsoh so dns_domain attribute in port/network is added only by the dns-integration extension? Is that correct?
14:57:58 <slaweq> ok
14:58:00 <ralonsoh> yes
14:58:07 <mlavalle> slaweq: yes
14:58:16 <frickler> designate is for global DNS, OVN will only answer internally, not?
14:58:27 <mlavalle> frickler: correct
14:58:32 <slaweq> but we'll really need very good document about that :)
14:58:36 <mlavalle> that's what it does today
14:58:38 <frickler> so the aboe == is wrong
14:58:38 <ralonsoh> slaweq, for sure
14:59:01 <slaweq> to explain once and forever what attribute or config option is when available and when responsible for what exactly
14:59:10 <ralonsoh> frickler, please, explain that
14:59:10 <slaweq> I think I at least understood it now
14:59:21 <slaweq> sorry for asking so many questions there :)
14:59:32 <mlavalle> slaweq: that's what we are here for
14:59:36 <elvira> 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 <lajoskatona> slaweq: that's the way we all learn new things
14:59:46 <lajoskatona> Our time is up
14:59:49 <lajoskatona> anyway
14:59:52 <mlavalle> slaweq: thanks for your questions
14:59:55 <frickler> 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 <ralonsoh> frickler, and this will be documented
15:00:26 <ralonsoh> but with this limit
15:00:29 <ralonsoh> the == is correct
15:00:45 <ralonsoh> and that was just to make the goal of this feature more clear
15:00:46 <lajoskatona> I think this RFE need a spec to have it all written
15:01:08 <slaweq> +1 for spec
15:01:45 <amotoki> +1 for spec. I am not against the idea but I agree more clarification is required :)
15:01:50 <ralonsoh> +1
15:02:14 <lajoskatona> +1 for the idea, and for more discussion in spec
15:02:33 <obondarev> +1
15:02:57 <mlavalle> ok, will write a spec. Thanks
15:03:26 <lajoskatona> mlavalle, elvira2: thanks for the proposal
15:03:32 <amotoki> really intersting discussion. neutron designate integration and dns support are really not easy to understand to capture the full context....
15:03:57 <lajoskatona> ok, I will update the RFE, with the comments
15:04:36 <lajoskatona> damiandabrowski[m]: sorry we had long discussion, we have to discuss another time your issue with gARP
15:04:52 <lajoskatona> #endmeeting