| opendevreview | Miguel Lavalle proposed openstack/neutron master: Enable HA for OVN router flavors https://review.opendev.org/c/openstack/neutron/+/901513 | 01:44 |
|---|---|---|
| opendevreview | Merged openstack/neutron stable/zed: Retry ``set|get_link_attribute(s)`` if the interface is not present https://review.opendev.org/c/openstack/neutron/+/910357 | 05:08 |
| opendevreview | Merged openstack/neutron stable/wallaby: Add max limit to agent_down_time https://review.opendev.org/c/openstack/neutron/+/905332 | 05:41 |
| opendevreview | Merged openstack/neutron master: Replace CRLF by LF https://review.opendev.org/c/openstack/neutron/+/906928 | 06:13 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Remove OVN_GATEWAY_INVALID_CHASSIS artifact https://review.opendev.org/c/openstack/neutron/+/909305 | 07:03 |
| opendevreview | Merged openstack/neutron master: [OVN] Identify the LR GW port with "external_ids:neutron:is_ext_gw" https://review.opendev.org/c/openstack/neutron/+/909311 | 07:53 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] "Logical_Router" pinned to chassis, OVN L3 scheduler https://review.opendev.org/c/openstack/neutron/+/909194 | 08:02 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Provide HA functionality to "Logical_Router" chassis pinning https://review.opendev.org/c/openstack/neutron/+/909437 | 08:02 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [eventlet] Do not monkey patch OVN agents https://review.opendev.org/c/openstack/neutron/+/910702 | 08:21 |
| opendevreview | Fernando Royo proposed openstack/ovn-bgp-agent master: Fix OVN LB Delete events for NB driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/905783 | 08:42 |
| opendevreview | Merged openstack/neutron stable/zed: Stable-Only: Temporary stop running grenade jobs on Zed https://review.opendev.org/c/openstack/neutron/+/910379 | 08:57 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Implement OVN agent metadata extension https://review.opendev.org/c/openstack/neutron/+/898238 | 09:10 |
| opendevreview | Sahid Orentino Ferdjaoui proposed openstack/neutron master: scheduler: make auto_scheduler_network uderstanding dhcp_agents_per_network https://review.opendev.org/c/openstack/neutron/+/910708 | 09:11 |
| opendevreview | Merged openstack/neutron-lib master: [netaddr>=1.0.0] Do not use netaddr.core.ZEROFILL flag with IPv6 https://review.opendev.org/c/openstack/neutron-lib/+/910331 | 09:28 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP - Add ``OVNGatewayHAChassisGroup`` scheduler class https://review.opendev.org/c/openstack/neutron/+/872033 | 09:38 |
| fnordahl | hum, two different tempest jobs failed in the same way on `tempest.api.identity.admin.v3.test_roles.RolesV3TestJSON.test_role_create_update_show_list`, I wonder if there is a breakage somewhere else | 09:41 |
| fnordahl | https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_0d9/878543/64/check/neutron-ovs-grenade-multinode-skip-level/0d9fc53/controller/logs/grenade.sh_log.txt | 09:41 |
| fnordahl | https://0aea9c217e86134e83d8-9ea232b51691ad27ed2d3f8993736155.ssl.cf1.rackcdn.com/878543/64/check/neutron-ovs-grenade-multinode/b169cfa/controller/logs/grenade.sh_log.txt | 09:41 |
| opendevreview | Fernando Royo proposed openstack/ovn-bgp-agent master: Fix OVN LB Delete events for NB driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/905783 | 09:43 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Set MTU of the VETH interfaces between OVS and metadata https://review.opendev.org/c/openstack/neutron/+/909684 | 10:18 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2023.2: [stable-only][OVN] Set VETH interface MAC address before up https://review.opendev.org/c/openstack/neutron/+/910714 | 10:29 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2023.1: [stable-only][OVN] Set VETH interface MAC address before up https://review.opendev.org/c/openstack/neutron/+/910715 | 10:29 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/zed: [stable-only][OVN] Set VETH interface MAC address before up https://review.opendev.org/c/openstack/neutron/+/910716 | 10:29 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2023.2: [OVN] Set MTU of the VETH interfaces between OVS and metadata https://review.opendev.org/c/openstack/neutron/+/910717 | 10:30 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2023.2: [OVN] Set MTU of the VETH interfaces between OVS and metadata https://review.opendev.org/c/openstack/neutron/+/910717 | 10:31 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2023.1: [OVN] Set MTU of the VETH interfaces between OVS and metadata https://review.opendev.org/c/openstack/neutron/+/910718 | 10:32 |
| opendevreview | Michel Nederlof proposed openstack/ovn-bgp-agent master: Add support for l3vpn with NB driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/906505 | 10:57 |
| opendevreview | Merged openstack/neutron master: [OVN][FT] Check ``WaitForCreatePortBindingEvent`` wait result https://review.opendev.org/c/openstack/neutron/+/910363 | 11:03 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add "socket" NUMA affinity policy https://review.opendev.org/c/openstack/neutron/+/910594 | 11:05 |
| opendevreview | Michel Nederlof proposed openstack/ovn-bgp-agent master: Add support for l3vpn with NB driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/906505 | 11:12 |
| opendevreview | Michel Nederlof proposed openstack/ovn-bgp-agent master: Add support for l3vpn with NB driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/906505 | 11:28 |
| opendevreview | Merged openstack/neutron master: [ovn] Ensure OVN DB update on change of number of GW ports https://review.opendev.org/c/openstack/neutron/+/909955 | 12:43 |
| haleyb | i am canceling the drivers meeting as there is nothing on the agenda, happy reviewing! and have a nice weekend | 14:01 |
| slaweq | thx haleyb | 14:01 |
| slaweq | have a nice weekend :) | 14:02 |
| ralonsoh | thanks | 14:02 |
| ralonsoh | haleyb, I'm checking the nested ovs routers | 14:02 |
| ralonsoh | and again, I can't forward the traffic | 14:02 |
| lajoskatona | thanks haleyb | 14:02 |
| ralonsoh | I have a live env right now | 14:02 |
| ralonsoh | I'm going to finish the testing with legacy and ha routers | 14:02 |
| haleyb | ralonsoh: i still have mine that is working, i just ran all the commands in the bug | 14:04 |
| lajoskatona | I retweet(X) my Tuesday question regarding openinfra days to have feedback from Other time zones also: | 14:04 |
| lajoskatona | bcafarel, elvira, mlavalle, mtomaska, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki: general question: do you know if you can travel to any of the OpenInfra days (https://openinfra.dev/days )? | 14:04 |
| lajoskatona | if yes we should sync it to meet and discuss (drink a beer :-)) in person and than I can start asking my management for travel budget :-) | 14:05 |
| haleyb | ralonsoh: well, the ml2/ovs is working, the ovn is not unless i apply the patch | 14:05 |
| ralonsoh | lajoskatona, I'm not in this list, I guess | 14:05 |
| ralonsoh | lajoskatona, sorry, I'll be in parental leave at this time | 14:05 |
| lajoskatona | ralonsoh: sorry, I copied it from somewhere.... | 14:05 |
| ralonsoh | haleyb, is this a all-in-one env? | 14:05 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-bgp-agent master: Bump OVS version (branch 3.3) for devstack local.conf sample https://review.opendev.org/c/openstack/ovn-bgp-agent/+/910491 | 14:05 |
| ralonsoh | I'm not saying this patch works, what I'm saying is that 1) I can't reproduce that with ml2/ovs (so I don't think this is a regression) | 14:06 |
| lajoskatona | ralonsoh: thanks, the question is more if we (E/// team) want to do the time consuming meetings with management for travel budget or just live with online meetings | 14:06 |
| ralonsoh | and 2) allowing the nating between a external network and other networks not directly attached to a router could be a security issue | 14:06 |
| ralonsoh | haleyb, is yours an all-in-one env? | 14:07 |
| haleyb | ralonsoh: but this is for nating an internal network using the default snat address to an external network | 14:07 |
| haleyb | yes, all in one | 14:07 |
| ralonsoh | haleyb, what I don't know is if your environment (the kernel) is somehow redirecting this traffic | 14:09 |
| ralonsoh | haleyb, what kind of router do you have? legacy, dvr or ha? | 14:09 |
| haleyb | Linux 22-04-ovs 6.5.0-21-generic #21~22.04.1-Ubuntu | 14:09 |
| haleyb | standard lts kernel | 14:09 |
| ralonsoh | I've seen some "gaps" with ml2/ovs | 14:10 |
| haleyb | ralonsoh: legacy, no dvr in this deployment | 14:10 |
| ralonsoh | for example, allowing snat from an internal network vm to an external vm using an OVS DVR router | 14:11 |
| ralonsoh | the same config but with HA router is not working | 14:11 |
| haleyb | so if you boot a vm on the nested network, you can't ping 8.8.8.8 ? | 14:11 |
| ralonsoh | and neither in oVN | 14:11 |
| ralonsoh | no, I can't | 14:11 |
| ralonsoh | I have this | 14:11 |
| ralonsoh | $ ping 10.0.0.221 | 14:11 |
| ralonsoh | PING 10.0.0.221 (10.0.0.221) 56(84) bytes of data. | 14:11 |
| ralonsoh | From 10.20.0.1 icmp_seq=1 Destination Net Unreachable | 14:11 |
| ralonsoh | From 10.20.0.1 icmp_seq=2 Destination Net Unreachable | 14:11 |
| ralonsoh | I'm still writing my comment in the LP bug | 14:11 |
| ralonsoh | because I've only tested with dvr routers | 14:11 |
| ralonsoh | I'm going to use now legacy and ha | 14:12 |
| ralonsoh | --> not finished reply in my buffer: https://paste.opendev.org/show/bmP3wxEqLMvwYcQjfwDp/ | 14:12 |
| haleyb | is that subnet from the v4 default pool? or same pool as the other subnet? | 14:13 |
| ralonsoh | haleyb, I'm not using subnet pools | 14:13 |
| ralonsoh | I have an external subnet (10.0.0.0/24), private1 (10.10.0.0/24) and private2 (10.20.0.0/24) | 14:14 |
| mlavalle | ralonsoh: I followed your suggestion here https://review.opendev.org/c/openstack/neutron/+/901513/19/neutron/services/ovn_l3/plugin.py#418. But now I hit this https://60a62e10d8b9b798ee87-e7edb05e06a1172316eb4206e173039e.ssl.cf1.rackcdn.com/901513/21/check/neutron-tempest-plugin-ovn/790b675/testr_results.html | 14:14 |
| mlavalle | ralonsoh: what do you suggest? | 14:14 |
| haleyb | that might have something to do with it, my memory is foggy but perhaps the different scope of the subnets is affecting forwarding | 14:15 |
| ralonsoh | different scope? | 14:15 |
| haleyb | ip rule type stuff, i'd have to check in the namespaces | 14:16 |
| ralonsoh | all subnets should not collide | 14:16 |
| ralonsoh | no no, we are not using address scopes | 14:16 |
| ralonsoh | mlavalle, I'll check it once I finish this ongoing issue | 14:17 |
| mlavalle | ralonsoh: thanks! | 14:17 |
| haleyb | ralonsoh: well your setup is different than mine not being all in one. but our customer has an ml2/ovs deployment that is working fine today, and it's 3-network nodes, multiple compute nodes | 14:21 |
| ralonsoh | haleyb, I would need to know what is the external network type and the router types | 14:22 |
| ralonsoh | haleyb, I'm checking now with other router types | 14:22 |
| haleyb | ralonsoh: so the VM you booted can ping the internal interface of the gw router, but not the external? | 14:24 |
| ralonsoh | no | 14:24 |
| ralonsoh | I can't ping router_ext GW port | 14:24 |
| haleyb | 10.20.0.1 is the internal IP? | 14:26 |
| ralonsoh | yes, router_ext internal IP | 14:26 |
| haleyb | that is responding to the ping with a dest unreach, hmm | 14:27 |
| * haleyb runs to get coffee | 14:27 | |
| opendevreview | Merged openstack/ovn-bgp-agent master: Bump OVS version (branch 3.3) for devstack local.conf sample https://review.opendev.org/c/openstack/ovn-bgp-agent/+/910491 | 14:27 |
| ykarel | lajoskatona, no plan to travel for those days | 14:32 |
| *** ykarel is now known as ykarel|away | 14:33 | |
| lajoskatona | ykarel: thanks | 14:34 |
| haleyb | lajoskatona: can you look at https://review.opendev.org/c/openstack/neutron/+/894399 again? it was only rebased since last ps | 14:43 |
| lajoskatona | haleyb: on it | 14:45 |
| ralonsoh | haleyb, with legacy routers (this is the first time I test them), I can ping | 14:45 |
| ralonsoh | but it is not possible with ha nor dvr | 14:46 |
| ralonsoh | so this is more a bug than a feature | 14:46 |
| haleyb | slaweq: can you look at https://review.opendev.org/c/openstack/neutron/+/909943 - and i might ping you about more reviews later :) | 14:46 |
| haleyb | ralonsoh: so i just reached out the the admin of this cloud, and it is running l3-ha with neutron gateway nodes (i.e. network nodes) | 14:48 |
| ralonsoh | no, I can't ping with HA routers | 14:49 |
| ralonsoh | only with legacy | 14:49 |
| haleyb | ralonsoh: so with dvr i wonder what is different, i can change my config. but the bug could be in dvr | 14:59 |
| ralonsoh | no no, I can't ping with HA nor DVR | 14:59 |
| ralonsoh | I don't know why your customer can with HA | 15:00 |
| ralonsoh | but I can't reproduce that with HA | 15:00 |
| ralonsoh | in any case, I'm now talking to some core OVN folks, raising this question of nested routing | 15:00 |
| ralonsoh | and if that should work and how | 15:00 |
| haleyb | ralonsoh: ack, thanks, my next step was going to be that ML but you have an inside track to them | 15:02 |
| opendevreview | Merged openstack/ovn-bgp-agent master: Fix address scope test and add address scope unit tests https://review.opendev.org/c/openstack/ovn-bgp-agent/+/907187 | 15:03 |
| haleyb | ralonsoh: https://bugs.launchpad.net/neutron/+bug/2029722 - i just remembered this bug, dvr has issues with this scenario, missing a rule | 15:04 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-bgp-agent stable/2023.2: Fix address scope test and add address scope unit tests https://review.opendev.org/c/openstack/ovn-bgp-agent/+/910618 | 15:04 |
| ralonsoh | haleyb, I've created the same env with OVN (never tested that before) | 15:33 |
| ralonsoh | haleyb, I can ping, from the internal VM to the ext GW port | 15:33 |
| haleyb | ack, but not the external network i'd guess | 15:33 |
| ralonsoh | yes | 15:34 |
| ralonsoh | the external network GW port | 15:34 |
| haleyb | ovn-nbctl lr-nat-list neutron-$routerid | 15:34 |
| ralonsoh | I have this in a devstack deployment, but I'm deploying now a multinode one | 15:35 |
| haleyb | stephenfin: can you take a look at https://review.opendev.org/c/openstack/python-openstackclient/+/887976 and the dependent? the code is basically merged in neutron but we don't have +W in the client repo. thanks! | 15:44 |
| stephenfin | I've held off approving anything this week as gtema told me not to | 15:44 |
| haleyb | fnordahl: is https://review.opendev.org/c/openstack/neutron/+/899402 still a WIP? | 15:44 |
| haleyb | stephenfin: oh, did we pass the client freeze? | 15:45 |
| stephenfin | I suspect so | 15:46 |
| stephenfin | If we have, we can backport this (there's no issues with feature backports). Otherwise, we could ask for a FFE (if those are a thing for client libs) | 15:46 |
| stephenfin | Probably best to ask gtema? | 15:46 |
| haleyb | stephenfin: ack, maybe i'm confused by the schedule | 15:48 |
| gtema | honestly speaking I am also not able to understand the schedule reliably | 15:49 |
| gtema | we are now in requirements freeze, soft strings freeze, final release for client libraries | 15:49 |
| haleyb | https://releases.openstack.org/caracal/schedule.html has a non-client and client library freeze, i figures python-openstackclient was the latter? | 15:50 |
| gtema | yes | 15:50 |
| gtema | and basically RM asked me last week to stop accepting anything | 15:50 |
| haleyb | gtema: "release management" ? i was going by the schedule | 15:51 |
| gtema | yes | 15:51 |
| gtema | I am also now looking at the schedule and not able to say for sure | 15:51 |
| haleyb | ¯\_(ツ)_/¯ | 15:53 |
| haleyb | i only see "Feb 26 - Mar 01" | 15:53 |
| gtema | right, on the other hand the final release itself is done | 15:54 |
| opendevreview | Merged openstack/ovn-bgp-agent stable/2023.2: Fix address scope test and add address scope unit tests https://review.opendev.org/c/openstack/ovn-bgp-agent/+/910618 | 15:55 |
| haleyb | gtema: ok, so we merge these to master (eventually), then backport to stable/2024.1 when it opens? | 15:56 |
| gtema | I'm currently asking release team | 15:56 |
| gtema | are we surely need this change in 2024.1 branch? I mean osc itself is a "rolling" stuff | 15:57 |
| haleyb | great, thanks, i'm in that channel too. it's more of a "feature complete" thing as we're updating the neutron guide | 15:58 |
| stephenfin | haleyb: One potential bug/optimisation noted in https://review.opendev.org/c/openstack/python-openstackclient/+/887976 | 16:07 |
| gtema | haleyb: so if you address changes till lets say mid of next week we can make this | 16:32 |
| haleyb | fnordahl: ^^ | 16:32 |
| haleyb | fnordahl: can't tell if one of the functional test failures in https://review.opendev.org/c/openstack/neutron/+/878543 is related to the change, test_gateway_chassis_rebalance | 17:02 |
| opendevreview | Vasyl Saienko proposed openstack/neutron master: Remove unneeded check in dhcp.py https://review.opendev.org/c/openstack/neutron/+/910208 | 17:36 |
| noonedeadpunk | I need some help now with understanding of how ovn-bgp-agent works with outgoing traffic. As it feels it does eerything as it's supposed to right now, but I'm missing 1 very-very important bit. I'm trying to use nb_ovn_bgp_driver and underlay exposing method | 17:39 |
| noonedeadpunk | So, I did have a working OVN deployment, and now trying to convert it to BGP one basically. As an br-ex I do have br-provider bridge. In clean OVN setup I have bond0 as part of br-provider, and then leveraged VLAN networks to get connectivity | 17:41 |
| noonedeadpunk | So, ovn-bgp-agent seems to do quite proper job at the momement, and creates all promised wiring and routing tables, as well as expose IPs through the FRR | 17:41 |
| noonedeadpunk | It did created br-provide.1001 vlan (which is defined in neutron as external VLAN network) and I do see traffic on it from VMs. | 17:42 |
| noonedeadpunk | And I dropped bond0 from br-provider bridge in OVN | 17:43 |
| noonedeadpunk | But the part I'm missing obviously - is how now to wire bond0 with br-provider? | 17:43 |
| noonedeadpunk | As I assume br-provider must still exist in OVS, so it makes it a valid bridge | 17:43 |
| noonedeadpunk | But then ovn-bgp-agent detects it, and uses more or less as simple interface? | 17:44 |
| noonedeadpunk | ie https://paste.openstack.org/show/b5lvx55Pp9AiWbV669lq/ | 17:47 |
| noonedeadpunk | but how in the world is should reach actual bond0.3102 as expected? | 17:47 |
| noonedeadpunk | Or well, maybe it should not be bond0.3102... but then what? | 17:48 |
| noonedeadpunk | or it should not use the OVS bridge name for it? as according to doc it is... | 17:49 |
| noonedeadpunk | so basically how I should wire/tell the path for external traffic (CR-LRP_IP) as it comes to br-ex.vlan and that's pretty much it... | 17:53 |
| noonedeadpunk | As I see statement "the physical NICs are not directly attached to br-ex" which exactly the case I have... But then how to wire these physical nics to br-ex... | 17:54 |
| noonedeadpunk | I feel I'm missing smth very basic and very stupid... | 17:56 |
| noonedeadpunk | So basically I can't understand how outgoing connectivity is reached, when physical interface is disconnected from br-ex | 18:15 |
| noonedeadpunk | and connect br-ex.3114 with bond0.3114 more or less? | 18:17 |
| noonedeadpunk | hm, ok, so actually I should have just left bond0 as part of the br-ex bridge despite what's written here https://docs.openstack.org/ovn-bgp-agent/latest/contributor/drivers/ovn_bgp_mode_design.html#proposed-solution | 18:19 |
| noonedeadpunk | "y contrast, in the default BGP driver solution (see [NB DB] NB OVN BGP Agent: Design of the BGP Driver with kernel routing), the physical NICs are not directly attached to br-ex, but rely on kernel networking (ip routes and ip rules) to redirect the traffic to br-ex." | 18:20 |
| noonedeadpunk | or probably that's for incoming traffic only.... | 18:20 |
| noonedeadpunk | but then it's also slightly wrong, as I'd need vlan->vlan mapping, and if bond0 is part of br-ex, then packets appear on bond0 directly, not vlan interface | 18:25 |
| mlavalle | haleyb: It's almost 8pm in Madrid. I don't think ralonsoh will follow up with me. I'll be on PTO next week. So I propose to go back to the way I was handling the extension in https://review.opendev.org/c/openstack/neutron/+/901513 | 18:54 |
| ralonsoh | mlavalle, no | 18:55 |
| ralonsoh | I'm working on this | 18:55 |
| ralonsoh | but no, we should not have an extension not declared in this list | 18:55 |
| ralonsoh | and no, this is a problem in n-t-p test | 18:55 |
| ralonsoh | instead of this, you can propose a patch in n-t-p testing what is happening in this test | 18:56 |
| ralonsoh | and why Neutron is returning an extension that is not loaded | 18:56 |
| ralonsoh | or should not be loaded because you are using ovn-router and not ovn-router-ha | 18:56 |
| mlavalle | ralonsoh: what is n-t-p testing? | 18:57 |
| mlavalle | ralonsoh: what is n-t-p testing? | 19:00 |
| ralonsoh_ | neutron-tempest-plugin | 19:00 |
| mlavalle | ralonsoh_: so what did you mean above when you said you were working on this? | 19:03 |
| ralonsoh_ | yes | 19:03 |
| mlavalle | what did you mean? what are you working on? | 19:04 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: TEST patch 901513 https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/910832 | 19:08 |
| ralonsoh_ | mlavalle, ^this | 19:08 |
| *** ralonsoh_ is now known as ralonsoh | 19:08 | |
| ralonsoh | mlavalle, these test are failing because Neutron is returning the extension "l3-ha", that should not be loaded because "ovn-router" plugin is used | 19:09 |
| ralonsoh | and not "ovn-router-ha" | 19:09 |
| ralonsoh | locally I can't reproduce this error: Neutron is returning the extensions loaded correctly (I don't see "l3-ha") | 19:10 |
| ralonsoh | but there is something wrong in the test | 19:10 |
| noonedeadpunk | hm, is this change does anything except set attribute to HA? Meaning - what are practical differences with current behaviour of L3 routers in OVN? | 19:10 |
| mlavalle | ralonsoh: ok, thanks. will wait for the results | 19:12 |
| noonedeadpunk | Just trying to understand for myself as don't see any obvious behaviour change in the patch | 19:12 |
| opendevreview | Michel Nederlof proposed openstack/ovn-bgp-agent master: Add support for l3vpn with NB driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/906505 | 19:13 |
| mlavalle | noonedeadpunk: there is no change in behavior for ovn routers. It is directed towards user defined router flavors | 19:13 |
| mlavalle | in that scenario, we just want to signal that ovn routers are ha by nature | 19:13 |
| mlavalle | that's all | 19:13 |
| noonedeadpunk | yeah, ok, thanks! | 19:13 |
| mlavalle | consistency in the API | 19:13 |
| noonedeadpunk | then probably we can easily change defaults to this new driver without changing anyones behaviour :) | 19:14 |
| ralonsoh | and why not to implement the API (same as for OVS ones) and do not allow to change it? | 19:14 |
| ralonsoh | because now we have an ovn router plugin that is not consistent with the API | 19:15 |
| ralonsoh | (same topic with DVR) | 19:15 |
| ralonsoh | actually what is proposed now, is a config driven API | 19:15 |
| ralonsoh | if ovn-router is selected, the ha API will fail | 19:15 |
| mlavalle | ralonsoh: what you mean is an extension? | 19:16 |
| ralonsoh | ha is an API extension, yes | 19:16 |
| ralonsoh | and is implemented for non-ovn routers | 19:16 |
| ralonsoh | but ovn routers don't implement it | 19:16 |
| mlavalle | ralonsoh: yeap, so far I follow | 19:16 |
| ralonsoh | so the proposal is to implement HA extension for ovn-router (and keep it as is now) | 19:17 |
| ralonsoh | and force, in the server, to always have ha=True in OVN | 19:17 |
| ralonsoh | (that is true and not configurable) | 19:17 |
| ralonsoh | and allow to create a router with and without "ha", the second one will fail in ml2/ovn | 19:18 |
| ralonsoh | and if we unset this "ha" in an ovn router, same error | 19:18 |
| mlavalle | my proposal at this point is to have HA = tue only when the ovn-router-ha is used | 19:18 |
| ralonsoh | (as long as we can't define a non-ha ovn router) | 19:18 |
| ralonsoh | yes but why? | 19:18 |
| ralonsoh | that makes no sense | 19:18 |
| opendevreview | Michel Nederlof proposed openstack/ovn-bgp-agent master: Add support for l3vpn with NB driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/906505 | 19:18 |
| ralonsoh | ovn-router is ha by default | 19:19 |
| ralonsoh | and always enabled | 19:19 |
| mlavalle | if the ovn-router plugin is used, the ha attribute is not not returned | 19:19 |
| ralonsoh | so enable it | 19:19 |
| ralonsoh | enable this extension in ovn-router | 19:19 |
| ralonsoh | and return this value | 19:19 |
| ralonsoh | and, by default, any new router will have ha=true | 19:19 |
| noonedeadpunk | yeah, that what confused me as well | 19:19 |
| ralonsoh | and if we try to create a non-ha ovn-rotuer, raise an exception | 19:20 |
| ralonsoh | same if we want to change an ovn-rotuer ha flag | 19:20 |
| noonedeadpunk | that a separate driver being defined makes most sense when behaviour is changed for end users | 19:20 |
| noonedeadpunk | and then you give user an option if to return HA router as HA or return HA as non-HA | 19:21 |
| ralonsoh | and I think my proposal will be easier to implement (this is what I initially think) | 19:21 |
| ralonsoh | mlavalle, in any case, because you'll be in PTO, I can propose something next monday and wait until you come back | 19:21 |
| mlavalle | ralonsoh: sure, go ahead, we can discuss when I come back | 19:22 |
| mlavalle | thanks! | 19:22 |
| ralonsoh | perfect | 19:22 |
| mlavalle | ralonsoh: the only point that I want to make is that I was trying to not have any changes in behavior, unless you are interested in router flavors | 19:23 |
| mlavalle | which is a very limited number of users | 19:23 |
| mlavalle | that is why I wnt that way | 19:23 |
| ralonsoh | ha and dvr API is a tech debt in the OVN router code | 19:24 |
| ralonsoh | so better to implement it | 19:24 |
| noonedeadpunk | well, reporting HA is HA is fair change in behaviour, if you'd ask me... | 19:24 |
| mlavalle | ok, cool, in that case we can kill two birds with one stone | 19:24 |
| noonedeadpunk | I can't imagine users complaining about it | 19:25 |
| ralonsoh | there will be, if the output change | 19:25 |
| mlavalle | ralonsoh: so yeah go ahead and propose something and we discuss when I come back | 19:25 |
| noonedeadpunk | I'd pretty much treat it as bugfix rather then feature... | 19:26 |
| noonedeadpunk | meaning - there was a tech debt and renderring was incorrect - it's fixed now | 19:26 |
| noonedeadpunk | but anyway:) | 19:26 |
| * noonedeadpunk was just looking for some help with ovn-bgp-agent... | 19:27 | |
| ralonsoh | noonedeadpunk, please open a LP bug, this is the best way to track an issue | 19:27 |
| ralonsoh | checking the IRC logs, I see a long description | 19:27 |
| ralonsoh | please report that in launchpad and we'll triage this bug next tuesday | 19:28 |
| noonedeadpunk | I don't think it's an issue. Rather I'm not getting a basic things | 19:28 |
| noonedeadpunk | (or they're not fully described in docs) | 19:28 |
| ralonsoh | I can help you very little with bgp agent | 19:29 |
| noonedeadpunk | As eventually agent does everything it promises to do | 19:29 |
| noonedeadpunk | but I'm not getting how traffic should exit br-ext.vlan interface and where it should flow further... | 19:29 |
| ralonsoh | maybe ltombaso, but on European working time | 19:29 |
| noonedeadpunk | ++ | 19:29 |
| noonedeadpunk | thanks, will try to bother folks on Monday | 19:30 |
| ralonsoh | it's 2030 for me, have a nice weekend | 19:30 |
| noonedeadpunk | same for me :p | 19:30 |
| opendevreview | Michel Nederlof proposed openstack/ovn-bgp-agent master: Add support for l3vpn with NB driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/906505 | 20:01 |
| fnordahl | this one has one +2, green CI and could use one more review and WF: https://review.opendev.org/c/openstack/neutron/+/878543 haleyb maybe? | 20:05 |
| haleyb | fnordahl: that's finally green? let me look | 20:07 |
| haleyb | fnordahl: approved, so i guess just the doc patch? it's still marked WIP | 20:08 |
| fnordahl | haleyb: thanks a bunch, really appreachiate all the time you and others have put into reviewing this series. Yes the doc did not progress as far as I hoped this week, got tied up in various review feedback and hunting CI issues, but I will not drop that | 20:13 |
| fnordahl | haleyb: I trust it would be OK to get the doc merged early next week? | 20:14 |
| fnordahl | It's the client patches too, but that is perhaps on a different release/freeze schedule | 20:15 |
| haleyb | fnordahl: yes, and we can always cherry-pick. and the client changes will probably need to do the same | 20:15 |
| fnordahl | I see there are some comments from Stephen, I'll look at those asap | 20:15 |
| opendevreview | Merged openstack/neutron master: [OVN] Remove OVN_GATEWAY_INVALID_CHASSIS artifact https://review.opendev.org/c/openstack/neutron/+/909305 | 20:38 |
| opendevreview | Merged openstack/neutron master: Make common Metadata Driver classes https://review.opendev.org/c/openstack/neutron/+/894399 | 20:59 |
| opendevreview | Merged openstack/neutron master: [ovn] Add support for enable_default_route_bfd attribute https://review.opendev.org/c/openstack/neutron/+/878543 | 23:04 |
| opendevreview | Merged openstack/neutron stable/xena: Add max limit to agent_down_time https://review.opendev.org/c/openstack/neutron/+/905331 | 23:05 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!