| ykarel | slaweq, hi | 08:30 |
|---|---|---|
| ykarel | when you get chance please check https://review.opendev.org/c/openstack/neutron-lib/+/826668 | 08:30 |
| ykarel | and https://review.opendev.org/c/openstack/neutron/+/826811 too | 08:31 |
| ykarel | Thanks in advance | 08:31 |
| slaweq | ykarel: sure | 08:46 |
| slaweq | I will finish one thing and will check those patches | 08:46 |
| opendevreview | Luis Tomas Bolivar proposed openstack/neutron stable/xena: Use Port_Binding up column to set Neutron port status https://review.opendev.org/c/openstack/neutron/+/823267 | 08:48 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: DNM Add some extra logs to debug DHCP issue in TripleO CI https://review.opendev.org/c/openstack/neutron/+/826999 | 08:50 |
| slaweq | ykarel: both patches reviewed | 09:00 |
| ykarel | Thanks slaweq | 09:01 |
| ykarel | slaweq, can u check https://review.opendev.org/c/openstack/neutron/+/826595 one too | 09:02 |
| ykarel | needed in stable branches only | 09:02 |
| ykarel | will backport to others once it's merged | 09:02 |
| slaweq | ykarel: done | 09:03 |
| ykarel | Thanks a lot | 09:03 |
| slaweq | you need also lajoskatona, ralonsoh or bcafarel to check it | 09:03 |
| ykarel | yeap i think i added them | 09:04 |
| ralonsoh | I'll take a look | 09:05 |
| ykarel | Thanks ralonsoh | 09:05 |
| ykarel | ralonsoh, also have you got chance to look into ovs tempest issue? | 09:05 |
| ykarel | i have seen multiple failures related to that | 09:06 |
| ralonsoh | what issue? | 09:06 |
| ykarel | let me fetch link, the one raised in last CI meeting | 09:06 |
| ykarel | https://etherpad.opendev.org/p/neutron-ci-meetings#L138 | 09:06 |
| ykarel | i have seen those only stable/wallaby patches | 09:07 |
| ykarel | not sure if other branches affected or not | 09:07 |
| ralonsoh | no, I didn't check this | 09:07 |
| ykarel | ok can you check this when get a chance | 09:08 |
| ykarel | i think i will report lp for this as seen multiple occurance already | 09:08 |
| ralonsoh | but why another LP bug? | 09:15 |
| ralonsoh | if there is one reported already | 09:15 |
| ykarel | i don't think it's already reported | 09:15 |
| ykarel | have u seen similar lp reported? | 09:16 |
| ykarel | ralonsoh, reported https://bugs.launchpad.net/neutron/+bug/1959564 | 09:27 |
| ykarel | if some other is already known, can mark it duplicate | 09:27 |
| * ykarel leaves for lunch | 09:28 | |
| lajoskatona | ykarel: thanks | 09:39 |
| *** dmellado_ is now known as dmellado | 09:45 | |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider stable/xena: Support creating members without a subnet ID https://review.opendev.org/c/openstack/ovn-octavia-provider/+/827010 | 09:46 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider stable/wallaby: Support creating members without a subnet ID https://review.opendev.org/c/openstack/ovn-octavia-provider/+/827011 | 09:51 |
| opendevreview | Merged openstack/neutron-lib stable/stein: Dropping lower constraints testing (stable Xena) https://review.opendev.org/c/openstack/neutron-lib/+/826668 | 10:14 |
| opendevreview | Bence Romsics proposed openstack/neutron stable/xena: Disable tracebacks of eventlet.wsgi.server https://review.opendev.org/c/openstack/neutron/+/827037 | 10:19 |
| opendevreview | Bence Romsics proposed openstack/neutron stable/wallaby: Disable tracebacks of eventlet.wsgi.server https://review.opendev.org/c/openstack/neutron/+/827038 | 10:20 |
| opendevreview | Bence Romsics proposed openstack/neutron stable/victoria: Disable tracebacks of eventlet.wsgi.server https://review.opendev.org/c/openstack/neutron/+/827039 | 10:20 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider stable/victoria: Support creating members without a subnet ID https://review.opendev.org/c/openstack/ovn-octavia-provider/+/827040 | 10:21 |
| opendevreview | Lajos Katona proposed openstack/tap-as-a-service master: DNM: test master https://review.opendev.org/c/openstack/tap-as-a-service/+/827043 | 10:28 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider stable/ussuri: Support creating members without a subnet ID https://review.opendev.org/c/openstack/ovn-octavia-provider/+/827045 | 10:42 |
| opendevreview | Merged openstack/neutron-lib stable/stein: Enforce policy for qos_policy_id attribute https://review.opendev.org/c/openstack/neutron-lib/+/826615 | 10:47 |
| ykarel | ralonsoh, if you can also check if https://review.opendev.org/q/Ib6b70114efb140cf1393b57ebc350fea4b0a2443 can cause those issues in wallaby ovs jobs | 10:50 |
| ralonsoh | ykarel, there is a bug open related to this | 10:50 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/826291 | 10:50 |
| ralonsoh | this is the patch | 10:51 |
| * ykarel looks | 10:52 | |
| ykarel | ralonsoh, ohkk that looks WIP, so simiilar needed in stable/wallaby too, ^ is proposed against stable/victoria? | 10:55 |
| ykarel | or we can revert stable/wallaby one until fixed | 10:56 |
| ralonsoh | not yet because the patch is not finished | 10:56 |
| ralonsoh | this is a security fix | 10:56 |
| ralonsoh | I wouldn't revert a security patch | 10:56 |
| ykarel | okk i meant temporary revert, but ok | 10:57 |
| ykarel | as it's affecting gates | 10:57 |
| opendevreview | Luis Tomas Bolivar proposed openstack/networking-ovn stable/train: Support creating members without a subnet ID https://review.opendev.org/c/openstack/networking-ovn/+/827051 | 11:02 |
| rubasov | ykarel, ralonsoh: if you see various random timeouts in tests that check connectivity over dhcp and/or router ports, that patch can definitely be the reason | 11:12 |
| rubasov | for some reason we did not see a single failure until the patch got backported to stable/victoria, but there it broke several dozen tests | 11:13 |
| rubasov | and after a recheck it breaks a quite different set of tests where the only common part is that those tests check for connectivity | 11:14 |
| ralonsoh | rubasov, I'm trying to create a list of flow calls | 11:14 |
| rubasov | but it should only break ovs based deployments | 11:14 |
| ralonsoh | to address your last reply there | 11:15 |
| ralonsoh | related to the flow deletion | 11:15 |
| rubasov | ralonsoh: that's the sure way to know | 11:15 |
| ralonsoh | why did you say the delete flow is executed in other transaction? | 11:15 |
| rubasov | if you see a flow with priority=65534 left around then that patch is guilty | 11:15 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/826460/3/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py | 11:15 |
| rubasov | because add_flow runs in dhcp/l3-agent | 11:16 |
| rubasov | but delete_flows runs in ovs-agent | 11:16 |
| ralonsoh | rubasov, sorry, who is setting the dead vlan tag? | 11:17 |
| rubasov | dhcp/l3-agent | 11:17 |
| rubasov | from replace_port() | 11:17 |
| ralonsoh | rubasov, can you point me to the code? | 11:18 |
| rubasov | a moment | 11:19 |
| rubasov | https://opendev.org/openstack/neutron/src/commit/30951fcdfab753153a30c4e77309da0b9afd919e/neutron/agent/common/ovs_lib.py#L379-L380 | 11:20 |
| rubasov | ^ setting the dead vlan tag | 11:20 |
| ralonsoh | rubasov, yes, but where in the DHCP code | 11:21 |
| opendevreview | yatin proposed openstack/neutron stable/xena: [Xena Only] Switch to xena neutron-tempest-plugin jobs https://review.opendev.org/c/openstack/neutron/+/827057 | 11:21 |
| rubasov | https://opendev.org/openstack/neutron/src/commit/30951fcdfab753153a30c4e77309da0b9afd919e/neutron/agent/linux/dhcp.py#L1696-L1703 | 11:22 |
| ralonsoh | rubasov, ok, so we are, sometimes, binding the device before we plug it? | 11:23 |
| opendevreview | yatin proposed openstack/neutron stable/xena: [Stable Only] Enforce policy for qos_policy_id attribute https://review.opendev.org/c/openstack/neutron/+/826595 | 11:24 |
| rubasov | that plug() call gets down to replace_port() which always sets the tag to the dead vlan tag | 11:25 |
| rubasov | I would not call that binding | 11:25 |
| ralonsoh | rubasov, the point is that the DHCP agent creates the port | 11:26 |
| opendevreview | Lucas Alvares Gomes proposed openstack/neutron master: [OVN] Migrate "reside-on-redirect-chassis" for distributed FIP https://review.opendev.org/c/openstack/neutron/+/826912 | 11:26 |
| ralonsoh | the OVS agent binds it and removes the dead vlan tag | 11:26 |
| rubasov | ralonsoh: yes, it does | 11:26 |
| ralonsoh | but sometimes this is not the order | 11:27 |
| ralonsoh | and we call the dead vlan tag removal before writing it | 11:27 |
| ralonsoh | pffff | 11:27 |
| rubasov | pretty much, but there's an important detail | 11:28 |
| rubasov | replace port operates in an ovsdb transaction | 11:28 |
| rubasov | but the attempted security fix also adds an extra flow right after that - which of course cannot be part of the ovsdb transaction since it's on openflow operation | 11:29 |
| rubasov | but before creating the port we don't know the ofport so we cannot pre-create the flow | 11:30 |
| rubasov | so I think there's no race in the ovsdb part, only in the openflow part | 11:30 |
| ralonsoh | yeah, we create the port with the tag and then we add the flow. At the same time that could be detected by the OVS agent that will try to bind it (and remove the flow) | 11:33 |
| rubasov | exactly | 11:34 |
| rubasov | and we need *something* to make the freshly plugged port actually dead (the access port tag + the dead vlan drop flow is not enough), otherwise the dead vlan leaks | 11:36 |
| rubasov | the attempted security fix tried to use the push dead vlan tag flow for this something | 11:37 |
| rubasov | but that lead to the race condition we have now | 11:38 |
| rubasov | regarding the comments you and Oleg left on https://review.opendev.org/c/openstack/neutron/+/826460 | 11:43 |
| rubasov | I don't think strict=False will solve the problem, because that could change the timing on one process, but it still races with the other process | 11:43 |
| ralonsoh | yes | 11:44 |
| ralonsoh | you are right on this | 11:44 |
| rubasov | and based on docs I also don't think any other vlan_mode would solve the problem | 11:44 |
| ralonsoh | the problem is between two processes | 11:44 |
| rubasov | but I couldn't actually test that yet - I was just putting together a play-environment for that | 11:45 |
| ralonsoh | no, that applies to flow commands in the same transaction | 11:45 |
| ralonsoh | now I realize this is because of a race condition between two agents | 11:45 |
| rubasov | but my thinking is that the ovs openflow pipeline does not see the access port tag, because that's an important optimization in ovs - to modify the frame as late as possible | 11:46 |
| rubasov | and that optimization will apply to the other vlan modes too | 11:46 |
| rubasov | plus ovs-vswitchd.conf.db.5 says that all vlan_modes apply only to "normal switching" | 11:48 |
| rubasov | it would be great to make the freshly plugged port dead by an ovsdb attribute (and then it would be dead right away in the transaction that created it) | 11:54 |
| rubasov | but is there any ovsdb attribute of a port that we can use for that purpose? | 11:54 |
| ralonsoh | rubasov, I was looking for that | 12:03 |
| rubasov | I'm testing Oleg's ideas with the vlan_modes | 12:04 |
| rubasov | I think I checked all relevant vlan_modes and they behave the same as an access port, that is openflow rules don't see the vlan set in the port's tag attribute | 12:19 |
| rubasov | (replied to Oleg's comment in the review with the details) | 12:19 |
| opendevreview | Marios Andreou proposed openstack/neutron master: DNM Revert "Call enable DHCP only if there are subnets with enabled DHCP in network" https://review.opendev.org/c/openstack/neutron/+/827014 | 12:30 |
| ralonsoh | rubasov, OK, I think we can add the flow BEFORE the port creation | 12:36 |
| ralonsoh | but that implies a change in ovsdbapp | 12:36 |
| ralonsoh | we can provide the port UUID | 12:36 |
| ralonsoh | one sec | 12:36 |
| rubasov | sounds interesting | 12:36 |
| ralonsoh | https://github.com/openvswitch/ovs/blob/master/python/ovs/db/idl.py#L2000-L2016 | 12:37 |
| ralonsoh | this is the call made to the ovs library from ovsdbapp | 12:37 |
| ralonsoh | we can provide a uudi | 12:37 |
| ralonsoh | new_uuid = uuid.uuid4() | 12:37 |
| ralonsoh | of course, that will imply a new ovsdbapp release | 12:38 |
| ralonsoh | but I think this is doable, I'll push a patch today | 12:38 |
| rubasov | let's give it a try, that would eliminate the performance effect of the currently proposed patch | 12:42 |
| ralonsoh | rubasov, my bad... | 12:42 |
| ralonsoh | what we need is the ofport... | 12:42 |
| ralonsoh | not the port/interface UUID... | 12:43 |
| rubasov | :-( | 12:43 |
| rubasov | at some point I was also thinking of "ovs-ofctl mod-port down", but since it's ofctl that's likely also implemented as an openflow operation | 12:51 |
| ralonsoh | right, same problem | 12:53 |
| rubasov | Oleg commented with one more new idea in the review | 12:56 |
| rubasov | in ovs does a trunk port always (regardless of the value of the trunks attribute) accept untagged frames? | 12:58 |
| ralonsoh | rubasov, ok, this is the deal: we can create an interface with an ofport_request | 12:58 |
| rubasov | if not, then Oleg's idea could work | 12:58 |
| ralonsoh | we can have, for example, a "reserved" list of ofports for DHCP ports | 12:58 |
| ralonsoh | from 64,000 to 65,279 | 12:59 |
| ralonsoh | the DHCP agent could create a flow before the port creation, with the ofport know in advance | 12:59 |
| rubasov | the price seems to be that we have to completely manage the ofport range, because there's no error when the ofport is already taken | 13:03 |
| rubasov | this gets ofport 10: ovs-vsctl add-port br0 port0 -- set Interface port0 type=internal ofport_request=10 | 13:04 |
| rubasov | but later this throws no error, just silently gets another ofport: ovs-vsctl add-port br0 port1 -- set Interface port1 type=internal ofport_request=10 | 13:04 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/ussuri: Fix race condition retrieving logical router rows https://review.opendev.org/c/openstack/ovn-octavia-provider/+/827077 | 13:15 |
| rubasov | and not just dhcp but each agent plug()-ing has to has its distinct ofport range | 13:17 |
| *** dasm|off is now known as dasm | 13:19 | |
| *** dasm is now known as dasm|rover | 13:19 | |
| ykarel | ralonsoh, slaweq when u get chance please check https://review.opendev.org/c/openstack/neutron/+/827057 | 13:20 |
| ykarel | need to clear xena gates | 13:20 |
| ykarel | would also need re workflow on https://review.opendev.org/c/openstack/neutron/+/826595 as rebased over ^ | 13:21 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Don't filter subnets based on segments if there is no host given https://review.opendev.org/c/openstack/neutron/+/827101 | 13:58 |
| ralonsoh | rubasov, ok, last try: how many ports can we have in a single host? | 14:02 |
| ralonsoh | 1,000? 5,000? | 14:03 |
| rubasov | I guess we can introduce new limits if we have to | 14:03 |
| ralonsoh | we have the OVS db locally cached in the IDL connection | 14:03 |
| rubasov | especially if we make it configurable | 14:03 |
| ralonsoh | that means we can easily read the interface ofports | 14:03 |
| ralonsoh | in a single iteration | 14:03 |
| ralonsoh | then we can figure out the free ofports in the system | 14:04 |
| ralonsoh | and chose one randomly | 14:04 |
| ralonsoh | ofport interval: | 14:04 |
| ralonsoh | ovs-vsctl: constraint violation: -1 is not in the valid range 1 to 65279 (inclusive) | 14:04 |
| ralonsoh | [1, 65279] | 14:04 |
| ralonsoh | we are not going to have more than 5,000 ports | 14:04 |
| ralonsoh | this is impossible to be handled by the OVS agent | 14:04 |
| ralonsoh | (dhcp, router, vms, etc) | 14:05 |
| rubasov | the previous idea (a configured distinct ofport range for each agent) sounded safer, because if we select randomly, then the dhcp and l3-agent on the same host will start racing and pick the same ofport eventually (the other order will not be atomic either) | 14:09 |
| ralonsoh | rubasov, how can we set an ofport range? | 14:09 |
| ralonsoh | now the interface does not define this parameter | 14:09 |
| ralonsoh | OVS will chose one but we can't set a limit | 14:10 |
| ralonsoh | apart from [1, 65279] | 14:10 |
| rubasov | I'm not saying I like this idea, just for the sake of going through the options: dhcp agent has a configurable range, let's say by default 64000-65000, we pass this down to ovs_lib, ovs_lib keeps track of the range usage, and pre-sets each ports ofport through ofport_request to a value known to be free | 14:15 |
| rubasov | then the silent ofport change can never happen | 14:15 |
| rubasov | and we can pre-install the flow | 14:15 |
| ralonsoh | no, I'm not saying to have a set of ofports for DHCP | 14:15 |
| ralonsoh | just when the port is going to be created list the used ofports and chose a free one | 14:16 |
| ralonsoh | we'll have many chances to use a free one that won't be used in this small period of time when we are creating this port | 14:16 |
| ralonsoh | of course, we can check if after the port creation | 14:17 |
| rubasov | but the "checking which ofport is free and take one" operation is not atomic therefore multiple agents plugging into the same ovs on the same host will race | 14:17 |
| ralonsoh | I know | 14:17 |
| ralonsoh | that's why I'm playing with the idea of "there will be only a little change of have this clash" | 14:18 |
| ralonsoh | because we first read, then create the OF rule and then create the port+interface | 14:18 |
| ralonsoh | during this time I know there is a change for other agent to create another interface with the same ofport | 14:18 |
| ralonsoh | chance* | 14:18 |
| rubasov | but have you considered the birthday problem, I'm not sure if that chance is as low as you would like | 14:20 |
| rubasov | and when it happens, it will be absolutely undebuggable | 14:20 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/ussuri: Fix race condition retrieving logical router rows https://review.opendev.org/c/openstack/ovn-octavia-provider/+/827077 | 14:21 |
| opendevreview | Luis Tomas Bolivar proposed openstack/neutron stable/wallaby: Ensure subports status is aligned with parent port https://review.opendev.org/c/openstack/neutron/+/826919 | 14:27 |
| obondarev | rubasov: Hi! please check my last comment in https://review.opendev.org/c/openstack/neutron/+/826460 - I think flow counter growing is ok. and next OVS would actually process the NORMAL action, where the packet will be dropped | 14:32 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: WIP Send packets to the QoS queue using OpenFlow rules https://review.opendev.org/c/openstack/neutron/+/827112 | 14:42 |
| rubasov | sorry guys, I have to take care of something else, I'll be away for about an hour | 14:43 |
| opendevreview | Merged openstack/neutron stable/xena: [Xena Only] Switch to xena neutron-tempest-plugin jobs https://review.opendev.org/c/openstack/neutron/+/827057 | 15:22 |
| opendevreview | Merged openstack/neutron stable/xena: [Stable Only] Enforce policy for qos_policy_id attribute https://review.opendev.org/c/openstack/neutron/+/826595 | 15:22 |
| opendevreview | Merged openstack/neutron stable/xena: [OVN] Add the VIF details "connectivity" parameter https://review.opendev.org/c/openstack/neutron/+/826438 | 15:23 |
| opendevreview | Krzysztof Tomaszewski proposed openstack/neutron master: Don't set HA ports down while L2 agent restart. https://review.opendev.org/c/openstack/neutron/+/826545 | 15:27 |
| opendevreview | yatin proposed openstack/neutron stable/wallaby: [Stable Only] Enforce policy for qos_policy_id attribute https://review.opendev.org/c/openstack/neutron/+/827015 | 15:54 |
| opendevreview | yatin proposed openstack/neutron stable/victoria: [Stable Only] Enforce policy for qos_policy_id attribute https://review.opendev.org/c/openstack/neutron/+/827016 | 15:54 |
| opendevreview | yatin proposed openstack/neutron stable/ussuri: [Stable Only] Enforce policy for qos_policy_id attribute https://review.opendev.org/c/openstack/neutron/+/827017 | 15:55 |
| opendevreview | Merged openstack/neutron stable/wallaby: [OVN] Add the VIF details "connectivity" parameter https://review.opendev.org/c/openstack/neutron/+/826439 | 15:57 |
| frickler | guess you could consider stable/victoria and older gates broken with pip 22 https://zuul.opendev.org/t/openstack/build/5749f117869f4ded9961017509c4b0f2 | 16:05 |
| ralonsoh | frickler, should we limit the pip version in stable releases? | 16:10 |
| ralonsoh | frickler, is there a bug in devstack open? | 16:11 |
| frickler | ralonsoh: it seems the main thing to do is use a specific version of get-pip.py. and I don't think there's a bug yet, feel free to create one | 16:16 |
| ralonsoh | thanks | 16:16 |
| slaweq | ralonsoh: mlavalle hi, when You will have some time, please check https://review.opendev.org/c/openstack/neutron/+/827101 which should help to solve issue with Tripleo CI jobs | 16:39 |
| ralonsoh | sure | 16:39 |
| mlavalle | slaweq: will do | 16:40 |
| slaweq | with this patch it seems that tripleo is green again: https://logserver.rdoproject.org/82/38582/4/check/periodic-tripleo-ci-centos-9-ovb-1ctlr_1comp-featureset002-master/ae3536a/ | 16:40 |
| slaweq | thx a lot | 16:40 |
| ralonsoh | slaweq, actually, when are we passing host? | 16:46 |
| ralonsoh | I see no call to this method using "host" | 16:46 |
| slaweq | ralonsoh: TBH I didn't check all calls of that method :) | 16:46 |
| slaweq | but that filtering if there is no host given doesn't makes any sense IMO | 16:47 |
| ralonsoh | slaweq, let me check that method and compare it to the older one | 16:47 |
| slaweq | sure | 16:47 |
| slaweq | I will not address any comments there today | 16:48 |
| slaweq | but tomorrow morning I would like to move on with this as this is "hot topic" in our cix call :) | 16:48 |
| opendevreview | Frode Nordahl proposed openstack/neutron master: [OVN] Extend port binding parameter validation https://review.opendev.org/c/openstack/neutron/+/818420 | 16:48 |
| opendevreview | Frode Nordahl proposed openstack/neutron master: WIP ovn: Off-path SmartNIC DPU Port Binding with OVN https://review.opendev.org/c/openstack/neutron/+/808961 | 16:48 |
| ralonsoh | slaweq, lajoskatona frickler https://review.opendev.org/c/openstack/devstack/+/827155 | 16:51 |
| lajoskatona | ralonsoh: wasn't this workarounded from some infra repo? | 16:54 |
| frickler | ralonsoh: you've used py syntax, not bash. and I think you need to make some more effort not to use the wrong pre-cached get-pip.py | 16:54 |
| ralonsoh | lajoskatona, I wasn't aware of it | 16:55 |
| ralonsoh | frickler, sorry, I don't understand | 16:55 |
| frickler | ralonsoh: I'll add a comment in the review | 16:56 |
| ralonsoh | thanks | 16:56 |
| opendevreview | Luis Tomas Bolivar proposed openstack/neutron stable/wallaby: Use Port_Binding up column to set Neutron port status https://review.opendev.org/c/openstack/neutron/+/827156 | 16:56 |
| lajoskatona | ralonsoh: I don't know, but there was a mail about it, so I guessed :-) | 16:57 |
| frickler | lajoskatona: ralonsoh: there are/were further issues that were dealt with on the infra-side, but some fix in devstack is also needed | 16:58 |
| lajoskatona | frickler: ack | 16:59 |
| opendevreview | Luis Tomas Bolivar proposed openstack/neutron stable/victoria: Use Port_Binding up column to set Neutron port status https://review.opendev.org/c/openstack/neutron/+/823271 | 17:07 |
| opendevreview | Luis Tomas Bolivar proposed openstack/neutron stable/ussuri: Use Port_Binding up column to set Neutron port status https://review.opendev.org/c/openstack/neutron/+/823272 | 17:10 |
| opendevreview | Arnau Verdaguer proposed openstack/neutron master: [OVN] Check if exists trunk ports before cleanup https://review.opendev.org/c/openstack/neutron/+/827158 | 17:18 |
| opendevreview | Luis Tomas Bolivar proposed openstack/networking-ovn stable/train: Use Port_Binding up column to set Neutron port status https://review.opendev.org/c/openstack/networking-ovn/+/823279 | 17:32 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVS] Add IPv6 ICMP RA to the default ingress rules https://review.opendev.org/c/openstack/neutron/+/827159 | 17:36 |
| opendevreview | Lajos Katona proposed openstack/neutron master: OVN TestOVNFunctionalBase add waiter for NB_Global https://review.opendev.org/c/openstack/neutron/+/825530 | 17:37 |
| *** tkajinam is now known as Guest1307 | 18:43 | |
| opendevreview | Frode Nordahl proposed openstack/neutron master: WIP ovn: Off-path SmartNIC DPU Port Binding with OVN https://review.opendev.org/c/openstack/neutron/+/808961 | 19:01 |
| opendevreview | Merged openstack/neutron master: Use elevated context to update router's external gateway https://review.opendev.org/c/openstack/neutron/+/826828 | 20:43 |
| opendevreview | Merged openstack/neutron stable/xena: When creating a VXLAN interface, a device is mandatory https://review.opendev.org/c/openstack/neutron/+/824752 | 22:12 |
| *** dasm|rover is now known as dasm|off | 22:29 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!