| opendevreview | Jakub Libosvar proposed openstack/ovn-bgp-agent master: WIP: Introduce multinode tempest job https://review.opendev.org/c/openstack/ovn-bgp-agent/+/936968 | 00:39 |
|---|---|---|
| opendevreview | Merged openstack/neutron master: Fix setting up functional test environment https://review.opendev.org/c/openstack/neutron/+/937106 | 01:21 |
| opendevreview | Liushy proposed openstack/neutron master: [ovn]Allow multiple IPv6 ports on router from same network https://review.opendev.org/c/openstack/neutron/+/936931 | 05:57 |
| *** elodilles_pto is now known as elodilles | 07:23 | |
| opendevreview | Andrew Bonney proposed openstack/neutron-fwaas-dashboard master: Fix remove port dialog for ha_router_replicated_interface https://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/937187 | 08:12 |
| opendevreview | Andrew Bonney proposed openstack/neutron-fwaas-dashboard master: Fix initial population of dropdowns in rule edit view https://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/937186 | 08:17 |
| opendevreview | Lajos Katona proposed openstack/tap-as-a-service master: GRE/ERSPAN mirroring for taas https://review.opendev.org/c/openstack/tap-as-a-service/+/885357 | 08:35 |
| opendevreview | Bodo Petermann proposed openstack/neutron master: Set IP/MAC address on VPNaaS gateway port (OVN) https://review.opendev.org/c/openstack/neutron/+/936850 | 09:05 |
| opendevreview | Slawek Kaplonski proposed x/whitebox-neutron-tempest-plugin master: Log packets captured by tcpdump on the nodes in case of test failure https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/937237 | 09:50 |
| opendevreview | Slawek Kaplonski proposed x/whitebox-neutron-tempest-plugin master: Log packets captured by tcpdump on the nodes in case of test failure https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/937237 | 10:08 |
| opendevreview | Lajos Katona proposed openstack/neutron-vpnaas master: DNM: test master https://review.opendev.org/c/openstack/neutron-vpnaas/+/937022 | 12:18 |
| opendevreview | Lajos Katona proposed openstack/neutron-vpnaas master: functional: Fix failing due to Noble and pip restricitons https://review.opendev.org/c/openstack/neutron-vpnaas/+/937022 | 12:20 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Optimization in the router port options generation https://review.opendev.org/c/openstack/neutron/+/937025 | 12:31 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Set always the GW LRP "gateway_mtu" option https://review.opendev.org/c/openstack/neutron/+/937026 | 12:32 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Improve initial hash ring setup https://review.opendev.org/c/openstack/neutron/+/936428 | 12:32 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Create a OVN hash ring maintenance thread per worker https://review.opendev.org/c/openstack/neutron/+/936838 | 12:32 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Fast exit when initially creating tunnel allocations https://review.opendev.org/c/openstack/neutron/+/936813 | 12:32 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Do not fail if the ACL does not exists in the deletion https://review.opendev.org/c/openstack/neutron/+/934409 | 12:32 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Create a OVN hash ring maintenance thread per worker https://review.opendev.org/c/openstack/neutron/+/936838 | 12:33 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Do not fail if the ACL does not exists in the deletion https://review.opendev.org/c/openstack/neutron/+/934409 | 12:33 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: DNM - Test "neutron-ovn-tempest-ipv6-only-ovs*" with 4 workers https://review.opendev.org/c/openstack/neutron/+/936429 | 12:33 |
| opendevreview | Candido Campos Rivas proposed x/whitebox-neutron-tempest-plugin master: Add the periodic CI queue https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/936925 | 12:34 |
| opendevreview | Candido Campos Rivas proposed x/whitebox-neutron-tempest-plugin master: [Routed provider tests]RHOSO adaptations https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/936762 | 12:34 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add a detailed debug message in case of segment allocation fail https://review.opendev.org/c/openstack/neutron/+/936171 | 12:35 |
| ralonsoh | slaweq, hello! please check https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/937041/1 if you have 1 min | 12:38 |
| ralonsoh | thanks! | 12:38 |
| haleyb | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Dec 6 14:00:58 2024 UTC and is due to finish in 60 minutes. The chair is haleyb. 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 |
| haleyb | Ping list: ykarel, mlavalle, mtomaska, slaweq, obondarev, tobias-urdin, lajoskatona, amotoki, haleyb, ralonsoh | 14:01 |
| mlavalle | \o | 14:01 |
| ralonsoh | hello | 14:01 |
| slaweq | o/ | 14:01 |
| s3rj1k | hi all | 14:01 |
| haleyb | alright, I see 4 items in the agenda, let's get started | 14:02 |
| haleyb | ralonsoh: the first two are yours | 14:02 |
| ralonsoh | I'm opening the agenda | 14:02 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2084782 | 14:02 |
| ralonsoh | [OVN] VLAN/flat LRP should be updated when the router networks are updated | 14:02 |
| lajoskatona | o/ | 14:03 |
| ralonsoh | summarizing: the problem here is that the funcionality right now doesn't work if we update the networks attached to a router | 14:03 |
| ralonsoh | if we have mixed type networks (tunnelled and not tunnelled), the flat/vlan ones need to be centralized | 14:03 |
| ralonsoh | due to issues in the MTU | 14:04 |
| ralonsoh | so the point is that we have been fixing/reverting this functionality several times | 14:04 |
| ralonsoh | my suggestion: | 14:04 |
| ralonsoh | 1) make always the vlan/flat network traffic centralized | 14:04 |
| ralonsoh | 2) propose a new feature to allow distributed vlan/flat traffic for routers with only this kind of networks | 14:05 |
| ralonsoh | (a kind of network type segregation) | 14:05 |
| ralonsoh | --> https://bugs.launchpad.net/neutron/+bug/2084782/comments/1 | 14:05 |
| obondarev | late o/ | 14:05 |
| ralonsoh | for (1) --> https://review.opendev.org/c/openstack/neutron/+/935652 | 14:06 |
| ralonsoh | so opinions here? | 14:06 |
| lajoskatona | what centralized means in this case with OVN? | 14:07 |
| ralonsoh | ovn allows distributed FIPs | 14:07 |
| ralonsoh | that won't work for flat/vlan networks connected to a router | 14:07 |
| ralonsoh | all traffic will cross the GW logical router port | 14:07 |
| lajoskatona | ahh, ok ,thanks | 14:08 |
| slaweq | so in fact we would make config option "enable_distributed_floating_ips" having no effect on the deployment, right? | 14:08 |
| slaweq | for the tenant networks of type vlan/flat | 14:09 |
| ralonsoh | for vlan/flat tenant networks | 14:09 |
| ralonsoh | yes | 14:09 |
| slaweq | for geneve networks it will still be distributed | 14:09 |
| ralonsoh | yes | 14:09 |
| slaweq | so basically it is revert of all the attemps to make vlan tenant networks to be distributed | 14:09 |
| ralonsoh | yes | 14:09 |
| ralonsoh | and (2) make this possible but only for these networks connected to a router | 14:10 |
| ralonsoh | not router type mixing | 14:10 |
| ralonsoh | right now this is a problem in OVN | 14:10 |
| ralonsoh | not network type mixing* | 14:10 |
| slaweq | and you know my opinion - I am ok with this as I know there is no other option and basically now we have this functionality broken in some cases | 14:10 |
| mlavalle | ah ok, so we are not ruling out distributed fips with vlan networks | 14:10 |
| slaweq | and there's no way to fix it for all use cases | 14:11 |
| opendevreview | Stanislav Dmitriev proposed openstack/neutron master: HA VRRP health check parameters https://review.opendev.org/c/openstack/neutron/+/932716 | 14:11 |
| mlavalle | it's just the mixing that we want to limit | 14:11 |
| ralonsoh | yes but we still allow that, but if we mix them | 14:11 |
| lajoskatona | if Iunderstand well the 2 options there will be some limitation anyway so have to choose which one :-) | 14:11 |
| ralonsoh | 1) tunnelled with have DVR | 14:11 |
| ralonsoh | 2) flat/vlan won't | 14:11 |
| mlavalle | yes, there's a limit in the proposal | 14:11 |
| ralonsoh | so we are not going to prevent mixing networks | 14:12 |
| ralonsoh | just disabling dvr for vlan | 14:12 |
| mlavalle | right, but... | 14:12 |
| mlavalle | if there are no tunneled networks, 2 will allow dvr for vlans, right? | 14:12 |
| slaweq | lajoskatona: yes, I see it like choose between: 1) mix network types in routers as you want but traffic to/from vlan tenant networks will be going throug chassis gw or 2) vlan tenant networks traffic will be distributed but you can't mix networks of different types in the same router | 14:13 |
| ralonsoh | mlavalle, no | 14:13 |
| ralonsoh | this is proposal (2) | 14:13 |
| slaweq | depends on the use case operator will be able to choose what the need | 14:13 |
| mlavalle | yes, thet's what I meant | 14:13 |
| slaweq | at least that's my understanding of the proposal | 14:13 |
| ralonsoh | and this is because if in the router you add a 3rd network, that is tunnelled, the vlan traffic will be broken | 14:13 |
| ralonsoh | mlavalle, right, I didn't read it correctly | 14:15 |
| ralonsoh | maybe, with future OVN improvements, we'll be able to avoid this limitations | 14:16 |
| opendevreview | Merged x/whitebox-neutron-tempest-plugin master: Bump hacking https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/936943 | 14:17 |
| mlavalle | is there a way we can fix this at the ovnlevel instead that at neutron's? | 14:17 |
| ralonsoh | yes but there are other limitations, for example with QoS | 14:17 |
| mlavalle | would a conversation with the ovn core team help? | 14:18 |
| ralonsoh | there is some kind of fix but that removes the qos capability for vlan networks | 14:18 |
| ralonsoh | so the solution introduces another issue\ | 14:18 |
| haleyb | so what will be the impact to a tenant (besides it actually working correctly), just a possible performance penalty for centralizing provider traffic? | 14:18 |
| haleyb | o | 14:19 |
| ralonsoh | right now we have this limitation, with mixed networks | 14:19 |
| ralonsoh | if we also implement (2) for vlan networks, this limitation will be gone | 14:19 |
| ralonsoh | (but, of course, using only vlan networks in the router, not mixing) | 14:19 |
| ralonsoh | right now we can't have everything | 14:20 |
| haleyb | right, but the use case of having both is probably pretty small, so we can live with it | 14:20 |
| ralonsoh | yes, that's the point | 14:20 |
| ralonsoh | usually tenant networks are geneve | 14:21 |
| ralonsoh | (that work much better in ovn) | 14:21 |
| mlavalle | that's a valid consideration | 14:21 |
| ralonsoh | if this is accepted, of course I'll document everything crystal clear | 14:22 |
| lajoskatona | that is necessary for sure | 14:22 |
| haleyb | with pictures or ascii art :) j/k doc is the key | 14:23 |
| obondarev | "but you can't mix networks of different types in the same router" what means "you can't"? Error raised on attempt to connect a diff type network to a router? | 14:23 |
| ralonsoh | if (2) is implemented and you add vlan networks to a router | 14:24 |
| ralonsoh | that will be configurable, in order to have DVR with vlan | 14:24 |
| ralonsoh | but that will imply that you won't be able to mix network types | 14:24 |
| ralonsoh | but this will be configurable (same as DVR, of example) | 14:24 |
| mlavalle | would that be for the entire deployment or per router? | 14:24 |
| haleyb | true, is that an API-type change? or ? | 14:24 |
| ralonsoh | per router | 14:24 |
| ralonsoh | haleyb, I don't think we can implement that at API level | 14:25 |
| obondarev | yeah I'm just thinking on upgrade scenario, when user already has mixed typed nets in a router | 14:25 |
| mlavalle | seems less restrictive then | 14:25 |
| ralonsoh | this is on the server, running time | 14:25 |
| ralonsoh | obondarev, by default, this config option will be disabled so the upgrade will be possible | 14:25 |
| obondarev | ack | 14:25 |
| ralonsoh | folks, I'm going to propose a spec | 14:26 |
| haleyb | ralonsoh: oh, per-router to me implied you can change it via the API | 14:26 |
| ralonsoh | this kind of change deserves it | 14:26 |
| slaweq | obondarev we can add some upgrade check to warn user about it durign upgrade | 14:26 |
| ralonsoh | it will be much better to describe everything there | 14:26 |
| lajoskatona | +1 for spec | 14:26 |
| ralonsoh | including upgrades or any other consideration | 14:27 |
| ralonsoh | I'll add the RFE tag to the bug | 14:27 |
| obondarev | +1 | 14:27 |
| haleyb | anyways, we should vote, and i was going to mention the RFE tag | 14:27 |
| haleyb | +1 | 14:27 |
| mlavalle | +1 | 14:28 |
| lajoskatona | +1 for the whole id and proposing solution for it | 14:28 |
| mlavalle | yes, my +1 assumes we implement (2) | 14:28 |
| ralonsoh | thanks folks, I'll propose this spec next week | 14:28 |
| haleyb | alright, great i marked it approved | 14:28 |
| haleyb | you also had the next item | 14:29 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2032817 | 14:29 |
| ralonsoh | issue: in a router, we handle ext MTU < int MTU | 14:29 |
| ralonsoh | but not the other way: ext MTU > int MTU | 14:29 |
| ralonsoh | this last case is rare but possible (there we have the bug) | 14:29 |
| ralonsoh | we have a flag in the GW LRP: options.gateway_mtu, that is set in the first case | 14:30 |
| ralonsoh | this sends a frag meesage to the VM to fragment the traffic, and works fine | 14:30 |
| ralonsoh | the proposal: to ALWAYS set this flag, regardless of the MTU relation | 14:30 |
| ralonsoh | that means, in a router with several networks and MTUs, the minimum MTU will define this value | 14:31 |
| ralonsoh | that makes sense if we want all networks to communicate | 14:31 |
| ralonsoh | this is, of course, a limitation in the performance | 14:31 |
| ralonsoh | but if you connect a network to a router you'll have this in consideration | 14:31 |
| ralonsoh | and, something else to be condifered, this is configurable: there is a neutron configuration flag in order to write or not this flag | 14:32 |
| ralonsoh | ovn_emit_need_to_frag | 14:32 |
| ralonsoh | better than this, the POC patch | 14:33 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/937026 | 14:33 |
| ralonsoh | (code speaks better than me) | 14:33 |
| haleyb | ok, so we will only set the mtu if the config option is set | 14:33 |
| ralonsoh | yes (this is True by default) | 14:34 |
| ralonsoh | and makes sense if we don't want issues with different MTUs | 14:34 |
| ralonsoh | this is just a heads-up because is an important change in the GW LRP | 14:34 |
| ralonsoh | so any comment can be done in the patch ^^^ | 14:34 |
| ralonsoh | thanks for listening (there are other topics in the agenda) | 14:34 |
| lajoskatona | thanks ralonsoh, makes the review easier | 14:35 |
| ralonsoh | thanks! | 14:35 |
| mlavalle | +1 | 14:35 |
| haleyb | ralonsoh: i agree with fixing, might need to clean-up gaps document where we added this, will put in review | 14:35 |
| haleyb | not sure we have to vote since it's technically a bug fix, but i'm +1 obviously | 14:37 |
| ralonsoh | no no, just a heads-up | 14:37 |
| ralonsoh | any review in the patch, thanks!! | 14:37 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/neutron master: [OVN] Do not supply gateway_port if it's not binded to chassis https://review.opendev.org/c/openstack/neutron/+/931495 | 14:37 |
| mlavalle | I just typed +1 to agree in that the clarification makes the revies easier | 14:37 |
| haleyb | ok, we have two more items | 14:37 |
| haleyb | s3rj1k: since i noticed you here, you can go next | 14:38 |
| haleyb | #link https://review.opendev.org/c/openstack/neutron-specs/+/935724 | 14:38 |
| s3rj1k | yea, so this is continuation of previous meeting | 14:38 |
| mlavalle | I thought so | 14:39 |
| s3rj1k | same toping, just prepared a spec for it | 14:39 |
| s3rj1k | *topic | 14:39 |
| ralonsoh | I'll check it next week, for sure | 14:39 |
| ralonsoh | I think we already voted for this one | 14:39 |
| mlavalle | we did | 14:39 |
| s3rj1k | yea, just highlighting this as needs review | 14:40 |
| ralonsoh | for sure, thanks! | 14:40 |
| mlavalle | thanks for the reminder | 14:40 |
| s3rj1k | we can continue on next items | 14:40 |
| haleyb | ok, next one was from Amir, not sure of his nick | 14:41 |
| ralonsoh | amnik, | 14:41 |
| amnik | Yes I'm here | 14:42 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2089726 | 14:42 |
| amnik | I get your points in review I want to share with you what I think now. | 14:42 |
| amnik | I also agree that it is not reasobable to implement parralel in ovsdbapp | 14:43 |
| amnik | Because affect all other project that use ovsdbapp | 14:44 |
| amnik | but in OVN agent I think order of events does not matter | 14:44 |
| opendevreview | Serhii Ivanov proposed openstack/neutron-specs master: Proposes `Agent Startup State Tracking` https://review.opendev.org/c/openstack/neutron-specs/+/935724 | 14:44 |
| amnik | so maybe we can implment parrale in OVN agent | 14:45 |
| amnik | in Ovn agent we always call provision_datapath in run function | 14:45 |
| noonedeadpunk | but comment for port DOWN/UP was a good example which was applicable for OVN | 14:45 |
| noonedeadpunk | in which state port wil result if it's done in parallel? | 14:45 |
| ralonsoh | noonedeadpunk, you can receive, as we are doing now in the CI, the port up and down events almost at the same time | 14:46 |
| amnik | and in provision_datapath we get the latest change of database independant of events | 14:46 |
| noonedeadpunk | ralonsoh: yes, but you would expect order matter, right? so you can't process these in parallel I assume? | 14:47 |
| ralonsoh | amnik, I'm totally ok with any improvement in the datapath provisioning. We had problems in the past because of this with beefy servers | 14:47 |
| ralonsoh | noonedeadpunk, that was my point in the comment in the patch | 14:47 |
| noonedeadpunk | yeah | 14:47 |
| ralonsoh | amnik, but you need to consider: | 14:47 |
| noonedeadpunk | I was just +1 it effectively here :) | 14:47 |
| ralonsoh | 1) the datapath will be dependant on a network | 14:48 |
| ralonsoh | 2) you can't process provisioning of a port in a datapath if other call is also doing the same for the same datapath | 14:48 |
| ralonsoh | 3) create threads in python to execute just python code doesn't improve performance | 14:49 |
| ralonsoh | that's all | 14:49 |
| lajoskatona | if we add parallelism for these low level operations do we gain anything or just have the extra headache with the complexity? | 14:50 |
| amnik | can you please explain the third one more. If we provosion datpath in multiple thread does not improve performance? | 14:50 |
| slaweq | lajoskatona: and new set of problems to debug in CI jobs 🙂 | 14:51 |
| ralonsoh | amnik, no, you are executing python code | 14:51 |
| lajoskatona | and debug customers :-) | 14:51 |
| lajoskatona | I mean their deployments | 14:51 |
| ralonsoh | lajoskatona, the only parts of this code that can maybe be executed in parallel are the pyroute calls to create/set the devices | 14:51 |
| noonedeadpunk | from what I saw main performance issues in neutron replies, was actually the way how policies are being processed... | 14:52 |
| ralonsoh | if we really want to improve this, we should refactor the code and create a dispatcher for several workers (processes) attending one datapath at the same time | 14:52 |
| ralonsoh | so you can receive events and send the operations to these workers | 14:52 |
| amnik | rolonsoh: I think the ovnmeta namespace maybe created parralely could help | 14:53 |
| ralonsoh | to prevent issues with parallel executions in the same datapath, only one worker should attend each datapath | 14:53 |
| ralonsoh | amnik, that takes 0.1 seconds | 14:53 |
| amnik | rolonsoh: I understand. | 14:54 |
| haleyb | ralonsoh: that's what the l3-agent does with it's work queues, indexed by network if my memory is good, but the GIL gets in the way | 14:54 |
| ralonsoh | so, again, I'll help and actively participate in a good improvement design for the OVN agent | 14:55 |
| ralonsoh | haleyb, kind of but the l3 agent and dhcp agent use threads | 14:55 |
| ralonsoh | and right now I lowered the working threads to 1 | 14:55 |
| ralonsoh | and there is no performance impact (and much better debugging and less issues) | 14:55 |
| ralonsoh | so if we want to do this, we need to create a server and spawn processes that will attend the requests | 14:56 |
| haleyb | yes, understood | 14:56 |
| ralonsoh | that is a HUGE refactor but I'll actively collaborate on this | 14:56 |
| amnik | ralonsoh: thanks, I will review your idea in this meeting. and propose RFE if I can help. | 14:57 |
| ralonsoh | perfect! | 14:57 |
| lajoskatona | don't we need a spec for such a refactor? | 14:58 |
| haleyb | ok, so based on that i will reject this current RFE | 14:59 |
| ralonsoh | we need first an idea hehehe | 14:59 |
| lajoskatona | ack | 14:59 |
| haleyb | and we need data showing it helps | 14:59 |
| haleyb | ok, we are out of time | 15:00 |
| slaweq | +1 for having some data which will show what is actually improved and by how much | 15:00 |
| amnik | Thanks all. I'll check it more. and contribute If I can help. | 15:00 |
| haleyb | thanks everyone for attending | 15:00 |
| haleyb | #endmeeting | 15:00 |
| opendevmeet | Meeting ended Fri Dec 6 15:00:54 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-12-06-14.00.html | 15:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-12-06-14.00.txt | 15:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-12-06-14.00.log.html | 15:00 |
| noonedeadpunk | Do you folks have an agenda somewhere for drivers meeting? | 15:00 |
| lajoskatona | Bye | 15:00 |
| ralonsoh | bye | 15:01 |
| mlavalle | \o | 15:01 |
| amnik | bye | 15:01 |
| slaweq | o/ | 15:01 |
| haleyb | noonedeadpunk: https://wiki.openstack.org/wiki/Meetings/NeutronDrivers - people add to on-demand at bottom | 15:01 |
| lajoskatona | noonedeadpunk:: https://bugs.launchpad.net/neutron/+bug/2089726 | 15:01 |
| s3rj1k | thanks, bye | 15:01 |
| noonedeadpunk | as I wanted to discuss some ovn-bgp thing, ie https://bugs.launchpad.net/ovn-bgp-agent/+bug/2088558 | 15:02 |
| noonedeadpunk | (or better ask for review&validity) | 15:02 |
| -opendevstatus- NOTICE: Gerrit on review.opendev.org is being upgraded to version 3.10 and will be offline. We have allocated an hour for the outage window lasting until 1700 UTC. | 15:03 | |
| vprokofev | hi haleyb, question regarding https://bugs.launchpad.net/neutron/+bug/2083214 if I may. It's been a while, spec is long there, it has been running in prod for some time. What's next? It seems I'm the only interested party to push this upstream, what should I do? Add it to agenda myself? Wait for someone to review it? I'm in a limbo at the moment. | 15:03 |
| -opendevstatus- NOTICE: Gerrit on review.opendev.org is being upgraded to version 3.10 and will be offline starting at 1600 UTC. We have allocated an hour for the outage window lasting until 1700 UTC. | 15:06 | |
| haleyb | vprokofev: sorry, i had not noticed the spec. i just added myself and will add it to the drivers agenda so at least it is mentioned in the next meeting | 15:19 |
| vprokofev | haleyb thank you. I hope it can be reviewed and we can move on, or I'll have to bug you about it again and again :) | 15:22 |
| haleyb | :) | 15:25 |
| sahid | o/ | 15:28 |
| sahid | hello guys, is this something that neutron still wants to do? https://bugs.launchpad.net/neutron/+bug/2087939 | 15:28 |
| sahid | i'm basically working downstream in that direction to avoid the connexion between agent and osvdb to be broken during intensive task of the agent | 15:28 |
| sahid | and noticed this bug report | 15:29 |
| sahid | it's a pretty old bug report, but indicated as confirmed | 15:29 |
| haleyb | sahid: yes, we are working on eventlet removal this cycle, see https://bugs.launchpad.net/neutron/+bugs?field.tag=eventlet-deprecation for all the bugs | 15:30 |
| haleyb | you can coordinate with ralonsoh as he added all those bugs | 15:31 |
| sahid | hum it is not so old actually why i'm saying that :-) | 15:31 |
| sahid | well yes i can, for the ovs agent part i can certainly help, i have also noticed that we will have to make some changes in ovsdbapp I guess | 15:32 |
| haleyb | sahid: thanks, and i wasn't aware of ovsdbapp changes, but if you see something please raise a bug and add that tag to it | 15:33 |
| opendevreview | Slawek Kaplonski proposed x/whitebox-neutron-tempest-plugin master: Log packets captured by tcpdump on the nodes in case of test failure https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/937237 | 15:35 |
| sahid | haleyb: cool, I will update the bug report regarding ovs agent, I have made a week of work around that part as this greenthread make us in a very bad shape, each time the connection is lost, the agent rebuild all the flows as there is a trigger that is saying bridge recreated | 15:36 |
| sahid | we basically have increased of_inacticity_probe to a larger value whihc solve the problem ofr most of the situation but when something does wrong with the env, that can make things even worst | 15:37 |
| sahid | anyway i'm gald to see that you are working on this point :-) | 15:37 |
| -opendevstatus- NOTICE: Gerrit on review.opendev.org is being upgraded to version 3.10 and will be offline momentarily. We have allocated an hour for the outage window lasting until 1700 UTC. | 16:01 | |
| opendevreview | Jakub Libosvar proposed openstack/ovn-bgp-agent master: WIP: Introduce multinode tempest job https://review.opendev.org/c/openstack/ovn-bgp-agent/+/936968 | 17:00 |
| opendevreview | Jakub Libosvar proposed openstack/ovn-bgp-agent master: WIP: Introduce multinode tempest job https://review.opendev.org/c/openstack/ovn-bgp-agent/+/936968 | 17:12 |
| opendevreview | Jakub Libosvar proposed openstack/ovn-bgp-agent master: WIP: Introduce multinode tempest job https://review.opendev.org/c/openstack/ovn-bgp-agent/+/936968 | 17:56 |
| opendevreview | Merged openstack/neutron-tempest-plugin master: [WSGI] Keep eventlet server for older versions of NDR https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/937041 | 18:39 |
| opendevreview | Brian Haley proposed openstack/neutron master: [OVN] QoS max and min rules should be defined in LSP for phynet ports https://review.opendev.org/c/openstack/neutron/+/934418 | 21:27 |
| opendevreview | Liushy proposed openstack/neutron master: Retry when metadata agent update chassis failed https://review.opendev.org/c/openstack/neutron/+/916387 | 21:47 |
| mlavalle | haleyb: just to be consistent with the same message, here to indicated the same document exist in the Neutron docs: https://bugs.launchpad.net/neutron/+bug/2091106/comments/1. What's the url of the document you were thinking of? | 21:48 |
| mlavalle | you indicated ^^^ | 21:49 |
| haleyb | mlavalle: i just did a grep for networkheresy - doc/source/admin/ovn/ovn.rst | 21:50 |
| haleyb | i think we can just remove the first section | 21:51 |
| haleyb | mlavalle: or just update to the correct url | 21:52 |
| haleyb | https://networkheresy.wordpress.com/2015/01/13/ovn-bringing-native-virtual-networking-to-ovs/ | 21:52 |
| opendevreview | Brian Haley proposed openstack/neutron master: Fix invalid url in OVN doc https://review.opendev.org/c/openstack/neutron/+/937296 | 21:55 |
| haleyb | voila! | 21:55 |
| mlavalle | haleyb: cool, thanks! have a nice weekend | 21:56 |
| haleyb | mlavalle: you too, was a good eod activity | 21:57 |
| mlavalle | haleyb: I | 21:57 |
| mlavalle | 'll assign the bug to you then | 21:57 |
| haleyb | I already did :) | 21:58 |
| haleyb | gets me $1 in salary to close a bug | 21:58 |
| mlavalle | wow, I would love a deal like that | 22:01 |
| mlavalle | :-) | 22:01 |
| haleyb | only 999,999 more to go | 22:01 |
| opendevreview | Brian Haley proposed openstack/neutron master: Support Guru Meditation Report(GMR) in agents https://review.opendev.org/c/openstack/neutron/+/932281 | 22:05 |
| opendevreview | Jakub Libosvar proposed openstack/ovn-bgp-agent master: WIP: Introduce multinode tempest job https://review.opendev.org/c/openstack/ovn-bgp-agent/+/936968 | 22:15 |
| opendevreview | Jakub Libosvar proposed openstack/ovn-bgp-agent master: WIP: Introduce multinode tempest job https://review.opendev.org/c/openstack/ovn-bgp-agent/+/936968 | 22:38 |
| opendevreview | Brian Haley proposed openstack/neutron master: Consume neutron-lib Context class project_id change https://review.opendev.org/c/openstack/neutron/+/936845 | 22:54 |
| opendevreview | Brian Haley proposed openstack/neutron-lib master: Support project_id and project_name in ContextBase class https://review.opendev.org/c/openstack/neutron-lib/+/935731 | 23:05 |
| opendevreview | Merged openstack/neutron-lib master: Add definition of the 'qinq' api extension https://review.opendev.org/c/openstack/neutron-lib/+/936841 | 23:20 |
| opendevreview | Brian Haley proposed openstack/neutron master: WIP: Remove false-positive ACLs in OVN DB sync https://review.opendev.org/c/openstack/neutron/+/937299 | 23:38 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!