| *** jlibosva is now known as Guest418 | 01:43 | |
| opendevreview | yangjianfeng proposed openstack/neutron master: [Agent Side] L3 router support ndp proxy https://review.opendev.org/c/openstack/neutron/+/744815 | 02:14 |
|---|---|---|
| opendevreview | yangjianfeng proposed openstack/neutron master: [Agent Side] L3 router support ndp proxy https://review.opendev.org/c/openstack/neutron/+/744815 | 04:42 |
| opendevreview | yatin proposed openstack/neutron master: [DNM] Layout test https://review.opendev.org/c/openstack/neutron/+/830930 | 05:00 |
| opendevreview | yatin proposed openstack/neutron master: [DNM] Layout test https://review.opendev.org/c/openstack/neutron/+/830930 | 05:03 |
| opendevreview | yatin proposed openstack/neutron master: Restructure layout for periodic,experimental and tox jobs https://review.opendev.org/c/openstack/neutron/+/830938 | 07:22 |
| opendevreview | yatin proposed openstack/neutron master: Re enable update_router_admin_state scenario test https://review.opendev.org/c/openstack/neutron/+/830812 | 07:26 |
| opendevreview | yatin proposed openstack/neutron master: Restructure layout for periodic, experimental and tox jobs https://review.opendev.org/c/openstack/neutron/+/830938 | 07:32 |
| opendevreview | yatin proposed openstack/neutron master: Re enable update_router_admin_state scenario test https://review.opendev.org/c/openstack/neutron/+/830812 | 07:32 |
| ykarel | slaweq, https://review.opendev.org/c/openstack/neutron/+/830938 should help in getting other periodic/experimental changes easily in | 07:35 |
| ykarel | i see u have few patches for those | 07:35 |
| slaweq | ykarel++ thx | 07:41 |
| slaweq | reviewed | 07:41 |
| ykarel | slaweq, ok if i rebase your those patches? as those conflict with this | 07:43 |
| ykarel | those already failed in zuul | 07:43 |
| slaweq | sure, thx | 07:45 |
| isabek | ralonsoh: Hi! Can you please take a look [1] ? Comments were resolved. Thanks in advance! 1) https://review.opendev.org/c/openstack/neutron/+/829522 | 07:46 |
| ykarel | k updating | 07:47 |
| opendevreview | yatin proposed openstack/neutron master: Move FIPS jobs from the experimental to the periodic queue https://review.opendev.org/c/openstack/neutron/+/830623 | 07:49 |
| opendevreview | yatin proposed openstack/neutron master: Add devstack-enforce-scope job to our periodic queue https://review.opendev.org/c/openstack/neutron/+/827302 | 07:53 |
| ralonsoh | isabek, sure | 08:06 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron stable/xena: [OVN] Handle RouterNotFound exception in set_gateway_mtu https://review.opendev.org/c/openstack/neutron/+/830864 | 08:09 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron stable/wallaby: [OVN] Handle RouterNotFound exception in set_gateway_mtu https://review.opendev.org/c/openstack/neutron/+/830865 | 08:10 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron stable/victoria: [OVN] Handle RouterNotFound exception in set_gateway_mtu https://review.opendev.org/c/openstack/neutron/+/830866 | 08:10 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron stable/ussuri: [OVN] Handle RouterNotFound exception in set_gateway_mtu https://review.opendev.org/c/openstack/neutron/+/830867 | 08:10 |
| ykarel | ralonsoh, hi | 08:13 |
| ykarel | ralonsoh, how u prep env for fullstack locally? do you used tools/configure_for_func_testing.sh script? | 08:14 |
| ykarel | asking as i am facing some issue in that, and wondering if it's just me | 08:14 |
| ralonsoh | ykarel, yes, this script | 08:16 |
| ykarel | to get it working i have to export DATABASE_USER=openstack_citest | 08:16 |
| ykarel | otherwise it picks root and fails for me | 08:16 |
| ralonsoh | let me check | 08:16 |
| ykarel | k Thanks | 08:17 |
| ralonsoh | ykarel, https://review.opendev.org/c/openstack/neutron/+/814009. There we change the zuul DB user | 08:38 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/814009/18/roles/configure_functional_tests/tasks/main.yaml | 08:38 |
| ralonsoh | but we don't change the user in the script | 08:38 |
| ralonsoh | I'll push a patch | 08:38 |
| ykarel | ralonsoh, i can push i have some other fix too | 08:38 |
| ykarel | in that script | 08:38 |
| lajoskatona | ykarel, ralonsoh: Hi, if there is a need to change doc for fullstack execution, please check this one also: https://docs.openstack.org/neutron/latest/contributor/testing/testing.html#id4 | 08:56 |
| ralonsoh | sure | 08:56 |
| ralonsoh | but I think this is just a matter of properly configure your env | 08:56 |
| ralonsoh | depending on the DB engine used | 08:56 |
| ykarel | lajoskatona, sure, i used that only | 08:56 |
| ykarel | and get issue with the script | 08:57 |
| ralonsoh | we should document that | 08:57 |
| ralonsoh | mysql: root | 08:57 |
| lajoskatona | ykarel: ok, thanks | 08:57 |
| ralonsoh | postgree: openstack_citest | 08:57 |
| ykarel | ralonsoh, but with root only i got issue with mysql | 08:58 |
| ykarel | the MYSQL_USER var is not getting used apart from setting DATABASE_USER var | 08:59 |
| ralonsoh | right, in L189 | 08:59 |
| ralonsoh | /usr/bin/mysql -u root -p"$MYSQL_PASSWORD" < $tmp_dir/mysql.sql | 09:00 |
| ralonsoh | we should use MYSQL_USER | 09:00 |
| ykarel | ralonsoh, ok can be done | 09:02 |
| ykarel | will see if other changes are needed for that | 09:02 |
| ralonsoh | folks, if you have 5 mins today: https://review.opendev.org/c/openstack/neutron/+/827683 | 09:16 |
| ralonsoh | thanks in advance | 09:16 |
| opendevreview | ZhouHeng proposed openstack/neutron-fwaas master: Revert "Retire neutron-fwaas project" https://review.opendev.org/c/openstack/neutron-fwaas/+/828149 | 09:19 |
| opendevreview | yatin proposed openstack/neutron master: Fix configure_for_func_testing script https://review.opendev.org/c/openstack/neutron/+/830949 | 09:22 |
| ykarel | ralonsoh, done ^ | 09:22 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron stable/xena: [OVN] Handle RouterNotFound exception in set_gateway_mtu https://review.opendev.org/c/openstack/neutron/+/830864 | 09:56 |
| opendevreview | ZhouHeng proposed openstack/neutron-fwaas master: Revert "Retire neutron-fwaas project" https://review.opendev.org/c/openstack/neutron-fwaas/+/828149 | 10:20 |
| opendevreview | Bogdan Dobrelya proposed openstack/neutron master: Log request IDs for matched Nova external events https://review.opendev.org/c/openstack/neutron/+/828687 | 10:25 |
| ykarel | ralonsoh, wrt https://review.opendev.org/c/openstack/neutron/+/794957 | 10:34 |
| ykarel | i had thought about using segment extension definition from neutron_lib, but as seperate patch | 10:35 |
| ralonsoh | ykarel, doesn't make sense | 10:35 |
| ralonsoh | the API is in n-lib, we should use it | 10:35 |
| ykarel | ralonsoh, i mean i agree to use from neutron-lib, but keep cleanup of standard_att_segment and use of segment definition from neutron-lib seperate | 10:36 |
| ykarel | but if you think it's better to do together i can update it | 10:36 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron stable/wallaby: [OVN] Handle RouterNotFound exception in set_gateway_mtu https://review.opendev.org/c/openstack/neutron/+/830865 | 10:42 |
| ykarel | ralonsoh, can you check https://review.opendev.org/c/openstack/neutron/+/830938 one | 10:43 |
| ralonsoh | ok | 10:44 |
| ykarel | Thanks | 10:45 |
| opendevreview | Merged openstack/neutron master: Bump python-neutronclient version to 7.8.0 https://review.opendev.org/c/openstack/neutron/+/829145 | 11:59 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Repeat few times put new interface in the namespace https://review.opendev.org/c/openstack/neutron/+/830622 | 12:20 |
| opendevreview | Luis Tomas Bolivar proposed openstack/networking-ovn stable/train: Check gateway IP while looking for LR plugged to LS https://review.opendev.org/c/openstack/networking-ovn/+/829576 | 13:06 |
| froyo | q gitano | 13:07 |
| froyo | sorry not this channel! :D | 13:08 |
| opendevreview | Luis Tomas Bolivar proposed openstack/networking-ovn stable/train: Allow to create ovn loadbalancer on dual-stack provider networks https://review.opendev.org/c/openstack/networking-ovn/+/830152 | 13:29 |
| congnt | Hello everyone, I want to ask a question about provider network. | 13:51 |
| congnt | I have a provider network /24, user use l3 to connect to Public (VM —> vRouter —> NAT to Provider Network —> Public. | 13:51 |
| congnt | If VM want Public IP, it can assign floating IP from provider network. | 13:51 |
| congnt | But my Old Provider Network run out of IP, I need add another CIDR to my openstack cluster. So can you suggest me a solution? | 13:51 |
| congnt | I find 3 solution but it have so problem | 13:51 |
| congnt | - If I add new subnet in old provider network, it will use same VLAN, and increase broadcast domain | 13:51 |
| congnt | - If I add new provider network. User can't assign floating IP from new provider network. User need to create another router, and set external gateway to new provider network, then the user can get the floating IP | 13:51 |
| congnt | - If use routed provider network, I only can to map one compute to one segment. E.g com1 map to segment1, com2 map to segment2, my VM reside in com1, but segment1 run out of IP, so i need migrate VM to com2 to get floating IP | 13:51 |
| congnt | If you have a best solution, please suggest for me. Thank you all so much! | 13:51 |
| opendevreview | yatin proposed openstack/neutron-tempest-plugin master: Re enable trunk_subport_lifecycle scenario test https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/830990 | 13:55 |
| lajoskatona | #startmeeting neutron_drivers | 14:00 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:00 |
| mlavalle | o/ | 14:00 |
| lajoskatona | o/ | 14:00 |
| slaweq | hi | 14:00 |
| amotoki | o/ | 14:00 |
| ralonsoh | hi | 14:01 |
| trident | o/ | 14:01 |
| rubasov | o/ | 14:02 |
| lajoskatona | Ok, I think we can start | 14:02 |
| damiandabrowski[m] | hi! | 14:02 |
| 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 |
| lajoskatona | this is from liuyulong | 14:02 |
| lajoskatona | to make ovs-agent send out RA packets | 14:03 |
| ralonsoh | is he going to present the RFE? | 14:05 |
| 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 |
| mlavalle | I don't see him around | 14:05 |
| mlavalle | and the information in Launchpad seems pretty concise | 14:06 |
| lajoskatona | yes and the feature is in line with the last ones from liuyulong | 14:06 |
| 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:06 |
| 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 |
| 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 |
| slaweq | but I know we already did things like e.g. dhcp in it so... | 14:07 |
| lajoskatona | slaweq: that's true, and ovs-agent is not an easy to understand/debug module | 14:08 |
| slaweq | it also has own performance/scalability problems already | 14:08 |
| amotoki | woops,,, sorry. I opened a different tab in a browse. | 14:09 |
| amotoki | please ignore my comment | 14:09 |
| slaweq | maybe it can be done as agent extension | 14:09 |
| ralonsoh | is this RFE going to be configurable? | 14:09 |
| lajoskatona | amotoki: no problem | 14:09 |
| ralonsoh | slaweq answered that | 14:09 |
| slaweq | then it could be enabled if needed only | 14:09 |
| ralonsoh | +1 to this | 14:10 |
| lajoskatona | I think if this is an optional feature it's not that bit problem | 14:10 |
| mlavalle | yeah, the agent extension approach addresses the debuggability / understability issue. Not the potential performance issue, though | 14:10 |
| lajoskatona | agree, +1 | 14:10 |
| lajoskatona | agent extension worked for the distributed dhcp also, so we can keep this aproach | 14:11 |
| ralonsoh | (now I recall, the DHCP feature should have been an extension too) | 14:11 |
| ralonsoh | DHCP feature is not an extension | 14:11 |
| ralonsoh | the code in implemented directly on the agent | 14:11 |
| 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 |
| mlavalle | with an extension approach | 14:12 |
| slaweq | ralonsoh yeah, and that's mistake, it should be an extension too | 14:12 |
| slaweq | mlavalle I know that it won't address performance problems but at least by default users will not have it enabled :) | 14:13 |
| ralonsoh | I would +1 this RFE commenting that this should be implemented as an OVS agent extension | 14:13 |
| mlavalle | yes, that's what I'm saying. Let's give operators the option and warn them of the potential performance problem | 14:13 |
| 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 |
| mlavalle | agree | 14:14 |
| ralonsoh | you are right on this | 14:14 |
| ralonsoh | (we have seen this problem frecuently in beefy compute nodes with 100s of VMs) | 14:14 |
| slaweq | ++ | 14:14 |
| amotoki | hehe, I saw it too | 14:15 |
| obondarev | hi, sorry for being late | 14:15 |
| ralonsoh | obondarev, https://bugs.launchpad.net/neutron/+bug/1961011 | 14:15 |
| ralonsoh | this is the topic now | 14:15 |
| obondarev | got it, makes sense for me | 14:16 |
| lajoskatona | ok, so I add the notes to the RFE to implement it as an agent extension | 14:16 |
| ralonsoh | +1 | 14:16 |
| mlavalle | +1 | 14:16 |
| haleyb | +1 from me | 14:16 |
| lajoskatona | +1 | 14:17 |
| obondarev | yeah, like recent one for dhcp extension | 14:17 |
| amotoki | +1 from me too | 14:17 |
| lajoskatona | ok, thanks, than accepted | 14:17 |
| lajoskatona | Next one: [RFE][OVN] Support DNS subdomains at a network level (#link https://bugs.launchpad.net/neutron/+bug/1960850 ) | 14:18 |
| ralonsoh | elvira2, ^ | 14:18 |
| slaweq | sorry, +1 from me to the previous one if it will be an extension :) | 14:19 |
| ralonsoh | elvira2, how will you pass this subdomain name? what kind of API do you propose? | 14:20 |
| ralonsoh | will it be a parity gap with OVS? | 14:20 |
| amotoki | I wonder what kind of changes we need in the API side to support this RFE. | 14:21 |
| amotoki | it is already what I think ralonsoh pointed. | 14:21 |
| mlavalle | I can answer these questions | 14:21 |
| mlavalle | I helped elvira2 putting together the RFE | 14:21 |
| 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:22 |
| 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 |
| elvira2 | but as mlavalle said, it should not require api changes as far as I'm concerned | 14:23 |
| ralonsoh | how a LS dns_domain is set? | 14:23 |
| obondarev | so it's OVN only option? | 14:24 |
| 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 |
| amotoki | ralonsoh: what is LS? | 14:24 |
| mlavalle | Logical Switch | 14:24 |
| slaweq | mlavalle didn't we made something like that in the past and later reverted it? | 14:24 |
| ralonsoh | OVN logical_swithc | 14:24 |
| ralonsoh | (a network in OVN) | 14:24 |
| amotoki | (ah.. thanks... i always use the full spelling :p) | 14:25 |
| mlavalle | ralonsoh: for each port in the OVN northbound DB there is a DHCP recors | 14:26 |
| mlavalle | record | 14:26 |
| opendevreview | Bogdan Dobrelya proposed openstack/neutron master: Log request IDs for matched Nova external events https://review.opendev.org/c/openstack/neutron/+/828687 | 14:26 |
| 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 |
| ralonsoh | not for each port, but for each subnet | 14:27 |
| mlavalle | today, we populate that DHCP record with the dns_domain from neutron.conf | 14:27 |
| ralonsoh | there is a dhcp_options record per subnet | 14:27 |
| amotoki | is there any difference from the perspective of VMs (neutron port consumers)? or no difference from VM? | 14:28 |
| opendevreview | Bogdan Dobrelya proposed openstack/neutron master: Log request IDs for matched Nova external events https://review.opendev.org/c/openstack/neutron/+/828687 | 14:29 |
| mlavalle | hang on a bit. I documented this a bit. Let me find it | 14:30 |
| 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:32 |
| *** elvira2 is now known as elvira | 14:32 | |
| mlavalle | but the underlying north bound DB has a dhcp record at the port level | 14:33 |
| 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 |
| mlavalle | please look here: https://paste.openstack.org/show/b2tfxZWOm3jbgJfkFlSo/ | 14:35 |
| ralonsoh | mlavalle, the dhc_options register is per subnet, not per port | 14:36 |
| 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 |
| mlavalle | ralonsoh: yes, in ML2 ovn | 14:36 |
| slaweq | or am I missunderstanding it? | 14:36 |
| mlavalle | slaweq: I'll get back to that in a minute | 14:37 |
| slaweq | ok, thx a lot | 14:37 |
| mlavalle | ralonsoh: but the underlying ovn db has it at the port level | 14:37 |
| ralonsoh | perfect | 14:37 |
| mlavalle | ralonsoh: please look at https://paste.openstack.org/show/b2tfxZWOm3jbgJfkFlSo/ | 14:37 |
| 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 |
| ralonsoh | right? | 14:38 |
| mlavalle | ralonsoh: correct. That will enable ml2 / ovn users to have a more flexible way to name their VMs | 14:39 |
| obondarev | AFAIU this will be new config option, not extension, is that correct? | 14:39 |
| ralonsoh | understood | 14:39 |
| mlavalle | as opposed to all the VMs in a flat domain defined in neutron.conf | 14:39 |
| ralonsoh | right, this should be configurable | 14:40 |
| elvira | yes, obondarev | 14:40 |
| mlavalle | correct | 14:40 |
| obondarev | ack, thanks | 14:40 |
| 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 |
| ralonsoh | inherit from the "farther", as in qos policies | 14:41 |
| ralonsoh | s/"father" | 14:41 |
| mlavalle | no we have have the dns_integgration extension | 14:41 |
| mlavalle | where ports use the dns_domain from their network | 14:42 |
| mlavalle | but we also have the dns_integration_port extension, where a port can have its own dns_domain | 14:42 |
| mlavalle | maybe that's not the name of the extension, but you get the idea | 14:43 |
| 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 |
| lajoskatona | malavalle: dns-domain-ports (https://opendev.org/openstack/neutron-lib/src/branch/master/neutron_lib/api/definitions/dns_domain_ports.py ) | 14:44 |
| mlavalle | lajoskatona: thanks, that's the one | 14:44 |
| mlavalle | so in essence, in OVS with DNS integartion we are doing what we are proposing for OVN | 14:45 |
| mlavalle | does that answer your question slaweq? | 14:45 |
| 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:46 |
| mlavalle | it is correct | 14:47 |
| 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:47 |
| 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 |
| mlavalle | yes, but we don't have that legacy in the OVN case | 14:48 |
| slaweq | sorry, but I'm always very confused with all those dns settings in Neutron :) | 14:48 |
| mlavalle | ml2 ovn is anyway doing its own thing with DHCp | 14:48 |
| mlavalle | which is https://docs.openstack.org/neutron/latest/contributor/internals/ovn/native_dhcp.html | 14:49 |
| slaweq | so do You propose to do things with network's/port's dns_domain attribute differently than in ML2/OVS case? | 14:49 |
| 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:49 |
| mlavalle | we are proposing extending the behavior documented in https://docs.openstack.org/neutron/latest/contributor/internals/ovn/native_dhcp.html | 14:50 |
| mlavalle | to be more flexible | 14:50 |
| mlavalle | leveraging the dns_domain attribute that already exists in the API for networks and ports | 14:50 |
| mlavalle | that's it | 14:51 |
| ralonsoh | that's the moment to properly document this feature, if implemented, in both backends | 14:52 |
| 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 |
| amotoki | *by this proposal | 14:52 |
| ralonsoh | OVN+this feature == OVS + designate | 14:52 |
| ralonsoh | this is the summary | 14:52 |
| 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 |
| lajoskatona | amotoki: agree, we need clear documentation | 14:52 |
| mlavalle | slaweq: yes, for ml2 / OVN | 14:53 |
| 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 |
| mlavalle | since ml2 / ovn does it's own thing anyway | 14:53 |
| mlavalle | regarding DHCP | 14:53 |
| slaweq | mlavalle but then You propose to have different API behavior depending on the backend used, right | 14:54 |
| slaweq | ? | 14:54 |
| mlavalle | that's the way it is today | 14:54 |
| mlavalle | we are just proposing making the OVN case more flexible | 14:55 |
| elvira | yes. This behaviour change should only be noticed if the configuration is explicitly changed and not by default, I think | 14:56 |
| ralonsoh | the point is that those dns extension are intended to work with OVS designate now | 14:56 |
| slaweq | TBH I'm not against it but for me it is confusing already and will be even more confusing probably :) | 14:57 |
| ralonsoh | if you use OVS without designate, you won't have this functionality | 14:57 |
| ralonsoh | OVS currently does not implement those features | 14:57 |
| mlavalle | ralonsoh: correct | 14:57 |
| ralonsoh | but will do natively | 14:57 |
| ralonsoh | so | 14:57 |
| ralonsoh | OVN+this feature == OVS + designate | 14:57 |
| slaweq | ralonsoh so dns_domain attribute in port/network is added only by the dns-integration extension? Is that correct? | 14:57 |
| slaweq | ok | 14:57 |
| ralonsoh | yes | 14:58 |
| mlavalle | slaweq: yes | 14:58 |
| frickler | designate is for global DNS, OVN will only answer internally, not? | 14:58 |
| mlavalle | frickler: correct | 14:58 |
| slaweq | but we'll really need very good document about that :) | 14:58 |
| mlavalle | that's what it does today | 14:58 |
| frickler | so the aboe == is wrong | 14:58 |
| ralonsoh | slaweq, for sure | 14:58 |
| slaweq | to explain once and forever what attribute or config option is when available and when responsible for what exactly | 14:59 |
| ralonsoh | frickler, please, explain that | 14:59 |
| slaweq | I think I at least understood it now | 14:59 |
| slaweq | sorry for asking so many questions there :) | 14:59 |
| mlavalle | slaweq: that's what we are here for | 14:59 |
| 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 |
| lajoskatona | slaweq: that's the way we all learn new things | 14:59 |
| lajoskatona | Our time is up | 14:59 |
| lajoskatona | anyway | 14:59 |
| mlavalle | slaweq: thanks for your questions | 14:59 |
| 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 | 14:59 |
| ralonsoh | frickler, and this will be documented | 15:00 |
| ralonsoh | but with this limit | 15:00 |
| ralonsoh | the == is correct | 15:00 |
| ralonsoh | and that was just to make the goal of this feature more clear | 15:00 |
| lajoskatona | I think this RFE need a spec to have it all written | 15:00 |
| slaweq | +1 for spec | 15:01 |
| amotoki | +1 for spec. I am not against the idea but I agree more clarification is required :) | 15:01 |
| ralonsoh | +1 | 15:01 |
| lajoskatona | +1 for the idea, and for more discussion in spec | 15:02 |
| obondarev | +1 | 15:02 |
| mlavalle | ok, will write a spec. Thanks | 15:02 |
| lajoskatona | mlavalle, elvira2: thanks for the proposal | 15:03 |
| amotoki | really intersting discussion. neutron designate integration and dns support are really not easy to understand to capture the full context.... | 15:03 |
| lajoskatona | ok, I will update the RFE, with the comments | 15:03 |
| lajoskatona | damiandabrowski[m]: sorry we had long discussion, we have to discuss another time your issue with gARP | 15:04 |
| lajoskatona | #endmeeting | 15:04 |
| opendevmeet | Meeting ended Fri Feb 25 15:04:52 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:04 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-02-25-14.00.html | 15:04 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-02-25-14.00.txt | 15:04 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-02-25-14.00.log.html | 15:04 |
| lajoskatona | Bye | 15:04 |
| ralonsoh | bye | 15:04 |
| amotoki | thanks all | 15:05 |
| slaweq | o/ | 15:05 |
| slaweq | have a great weekend @all | 15:05 |
| damiandabrowski[m] | ok :( | 15:05 |
| mlavalle | o/ | 15:05 |
| lajoskatona | slaweq: thanks, and have a great weekend | 15:05 |
| trident | lajoskatona: Do you have a proposal on when to discuss the gARP issue? Next neutron_drivers meeting? Will it stay as a point on the agenda? | 15:07 |
| lajoskatona | trident: yes, of course I add it | 15:08 |
| ralonsoh | slaweq, if you have 1 min https://review.opendev.org/c/openstack/neutron-lib/+/828738 | 15:08 |
| trident | lajoskatona: Great, thanks! Have a nice weekend! | 15:09 |
| lajoskatona | trident: the same to you :-) | 15:09 |
| *** ykarel is now known as ykarel|away | 15:22 | |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Update VIP port host ID when traffic detected https://review.opendev.org/c/openstack/neutron/+/830624 | 15:37 |
| ralonsoh | mlavalle, hi, if you have time https://review.opendev.org/c/openstack/neutron/+/827683 | 15:45 |
| mlavalle | ralonsoh: yes, I'll look at it during the day | 15:47 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add port IDs in "RouterInUse" exception during router deletion https://review.opendev.org/c/openstack/neutron/+/830813 | 15:47 |
| mlavalle | damiandabrowski[m]: I'm sorry you didn't get time during the meeting. Your RFE will be the first one next week | 15:49 |
| damiandabrowski[m] | it's ok ;) I'm on vacation next week, but maybe trident can take it over | 15:50 |
| damiandabrowski[m] | if not, the only option I see is to postpone it by 2 weeks | 15:50 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Repeat few times put new interface in the namespace https://review.opendev.org/c/openstack/neutron/+/830622 | 15:53 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Rehome exception ``L3ExtensionException`` https://review.opendev.org/c/openstack/neutron-lib/+/831002 | 16:00 |
| opendevreview | Merged openstack/neutron master: [Fullstack] Block until dhcp config is done https://review.opendev.org/c/openstack/neutron/+/830732 | 16:09 |
| opendevreview | Merged openstack/neutron master: Revert "[Fullstack] Mark security groups test as unstable" https://review.opendev.org/c/openstack/neutron/+/830374 | 16:09 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: [WIP] Retry of logical switch association to the load balancer for large networks https://review.opendev.org/c/openstack/ovn-octavia-provider/+/829126 | 16:29 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Update VIP port host ID when traffic detected https://review.opendev.org/c/openstack/neutron/+/830624 | 17:49 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP][L3] QoS inherit network https://review.opendev.org/c/openstack/neutron/+/819147 | 18:27 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add port IDs in "RouterInUse" exception during router deletion https://review.opendev.org/c/openstack/neutron/+/830813 | 18:31 |
| *** marlinc is now known as Guest547 | 21:15 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!