| opendevreview | ZhouHeng proposed openstack/neutron master: Improve ACL comparison efficiency https://review.opendev.org/c/openstack/neutron/+/885449 | 00:11 |
|---|---|---|
| opendevreview | ZhouHeng proposed openstack/neutron master: Improve ACL comparison efficiency https://review.opendev.org/c/openstack/neutron/+/885449 | 01:23 |
| opendevreview | ZhouHeng proposed openstack/neutron master: Improve ACL comparison efficiency https://review.opendev.org/c/openstack/neutron/+/885449 | 01:31 |
| opendevreview | OpenStack Proposal Bot proposed openstack/neutron master: Imported Translations from Zanata https://review.opendev.org/c/openstack/neutron/+/895526 | 04:25 |
| 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 | 07:50 |
| opendevreview | Merged openstack/neutron-vpnaas-dashboard master: Imported Translations from Zanata https://review.opendev.org/c/openstack/neutron-vpnaas-dashboard/+/882655 | 07:54 |
| SvenKieske | can someone take a look at https://bugs.launchpad.net/kolla-ansible/+bug/2033980 ? it was filed against kolla-ansible but I analyzed it for a bit and this has to do with how neutron handles spawning and especially killing radvd and I want to be sure that's not a bug in neutron. | 08:33 |
| SvenKieske | I still don't understand line 248 in utils.py: "return converter(f.read()) if converter else f.read()" where does this "converter" come from? is that some helper function in neutron? I was not able to find it, yet. | 08:35 |
| opendevreview | ZhouHeng proposed openstack/neutron master: DNM: test remove some rpc message https://review.opendev.org/c/openstack/neutron/+/894891 | 08:38 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron stable/xena: [OVN] Fix rate and burst for stateless security groups https://review.opendev.org/c/openstack/neutron/+/895783 | 08:57 |
| opendevreview | Merged openstack/neutron stable/zed: Add 3 secs to wait for keepalived state change https://review.opendev.org/c/openstack/neutron/+/895667 | 10:44 |
| opendevreview | Merged openstack/neutron stable/yoga: Add 3 secs to wait for keepalived state change https://review.opendev.org/c/openstack/neutron/+/895668 | 10:44 |
| opendevreview | Merged openstack/neutron stable/xena: Add 3 secs to wait for keepalived state change https://review.opendev.org/c/openstack/neutron/+/895669 | 10:44 |
| opendevreview | Merged openstack/neutron stable/wallaby: Add 3 secs to wait for keepalived state change https://review.opendev.org/c/openstack/neutron/+/895670 | 10:44 |
| *** ralonsoh_ is now known as ralonsoh | 11:07 | |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add a "port" child table "porthardwareoffloadtype" https://review.opendev.org/c/openstack/neutron/+/882832 | 11:09 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/wallaby: Revert "[OVN][Trunk] Add port binding info on subport when parent is bound" https://review.opendev.org/c/openstack/neutron/+/894790 | 11:17 |
| ralonsoh | bcafarel, hi! if you have some minutes: https://review.opendev.org/q/Ifc2d37e2042fad43dd838821953defd99a5f8665 | 11:35 |
| ralonsoh | thanks in advance | 11:35 |
| bcafarel | ralonsoh: sure, looking! | 11:46 |
| bcafarel | ralonsoh: this needs a 2023.2 one too (and make sure we have it in a new rc?) | 11:49 |
| ralonsoh | bcafarel, well yeah, because it didn't land in 2023.2 when it was master | 11:49 |
| ralonsoh | I'll propose a patch | 11:49 |
| gthiemonge | Hi Folks, in Octavia, we have some (old) code that disables a port (admin_state_up=False) that is connected to a VM, then waits for the status of the port to be DOWN: https://opendev.org/openstack/octavia/src/commit/5ce85105c9b9211df9f2d88c8f1f543120eabaf4/octavia/controller/worker/v2/tasks/network_tasks.py#L1060-L1074 | 12:16 |
| gthiemonge | but the status is always ACTIVE | 12:16 |
| gthiemonge | I think this behavior changed when we switched to ML2/OVN by default, does it ring a bell? should the status be DOWN for disabled ports? | 12:17 |
| sahid_ | o/ | 12:22 |
| sahid_ | quick question guys, we have in our env 4 neutron servers, wierdly there is one that is taking 4x time more activities time to time | 12:23 |
| sahid_ | it's always the same | 12:24 |
| sahid_ | we have tried to stop it but then an other neutron server took that same kind of pattern | 12:24 |
| sahid_ | so it's not related to the machine | 12:24 |
| sahid_ | what could take more activity for a given neutron server compared to the other | 12:26 |
| sahid_ | I guess it's not API related as that should be well disptached | 12:26 |
| sahid_ | so I imagine it is rpc based | 12:26 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron stable/wallaby: [OVN] Fix rate and burst for stateless security groups https://review.opendev.org/c/openstack/neutron/+/895785 | 12:45 |
| ralonsoh | gthiemonge, status for disabled ports is always DOWN | 12:53 |
| ralonsoh | what do you expect? the transition? the status? | 12:53 |
| ralonsoh | just to understand the OVS-OVN difference | 12:54 |
| gthiemonge | ralonsoh: I expect it to be DOWN, but it's ACTIVE | 12:57 |
| ralonsoh | ok, let me check that first (without octavia) | 12:57 |
| gthiemonge | https://paste.opendev.org/show/bmCJ7UgnQb0SJnKpdIS2/ | 12:58 |
| gthiemonge | for instance ^ this port is disabled and bound, but status is ACTIVE | 12:58 |
| lajoskatona | ralonsoh, gthiemonge: with OVS my bound port status is DOWN after I set admin_state_up=False | 13:01 |
| lajoskatona | ralonsoh, gthiemonge: I have no working OVN env now :-( | 13:01 |
| ralonsoh | ok, that sounds like a bug, but I need to check | 13:04 |
| ralonsoh | in ML2/OVN, if you disable the port, the status=ACTIVE | 13:04 |
| lajoskatona | sahid_: good question, with enough rpc_wprkers that could be ok, I think this is the step one document for rpc workers: https://docs.openstack.org/neutron/latest/admin/config-wsgi.html#neutron-worker-processes | 13:06 |
| sahid_ | oh yes interesting point... | 13:11 |
| sahid_ | "For rpc_workers, there needs to be enough to keep up with incoming events from the various neutron agents. Signs that there are too few can be agent heartbeats arriving late, nova vif bindings timing out on the hypervisors, or rpc message timeout exceptions in agent logs (for example, “broken pipe” errors)." | 13:11 |
| sahid_ | lajoskatona: thank you | 13:11 |
| SvenKieske | I _think_ I found a bug in the external_process.py handling of removing pid files, but I'm not 100% sure as I'm really no neutron expert, maybe someone can take a look at my last comment here: https://bugs.launchpad.net/kolla-ansible/+bug/2033980 | 13:19 |
| ralonsoh | SvenKieske, will triage this bug during the next meeting. The handling of an external process is done using the same class (dnsmasq, radvd, keepalived, etc). But of course here there could be some additional condition | 13:26 |
| SvenKieske | ralonsoh: thank you! I suspect it's due to external killing or rather crashing of the radvd process, it's a little complicated to debug. | 13:29 |
| SvenKieske | I can see there are some test cases around that, mhmm, weird. | 13:31 |
| SvenKieske | ah but the unit test cases always directly seem to test eventlet, maybe it's due to the ProcessManager wrapper, anyway thanks for looking into it! I guess you can find the problem way faster then me :) | 13:32 |
| opendevreview | Lajos Katona proposed openstack/tap-as-a-service master: WIP: CLI for Tap Mirrors https://review.opendev.org/c/openstack/tap-as-a-service/+/886085 | 13:45 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add a "port" child table "porthardwareoffloadtype" https://review.opendev.org/c/openstack/neutron/+/882832 | 13:47 |
| gthiemonge | ralonsoh: (sorry I was in a meeting) should I report a bug for ml2-ovn? | 13:50 |
| ralonsoh | yes please | 13:50 |
| ralonsoh | we should at least investigate why we have this difference between mech drivers | 13:51 |
| *** obondarev_ is now known as obondarev | 14:00 | |
| ralonsoh | Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slawek, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki | 14:01 |
| lajoskatona | o/ | 14:01 |
| frickler | \o | 14:01 |
| mtomaska | o/ | 14:01 |
| jlibosva | o/ | 14:01 |
| obondarev | o/ | 14:01 |
| ralonsoh | #startmeeting networking | 14:01 |
| opendevmeet | Meeting started Tue Sep 19 14:01:42 2023 UTC and is due to finish in 60 minutes. The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| opendevmeet | The meeting name has been set to 'networking' | 14:01 |
| mlavalle | o/ | 14:01 |
| ralonsoh | hello all | 14:01 |
| rubasov | o/ | 14:01 |
| elvira | o/ | 14:02 |
| haleyb | o/ (in another meeting if i'm slow) | 14:02 |
| slaweq | o/ | 14:02 |
| ralonsoh | #topic announcements | 14:02 |
| ralonsoh | #link https://releases.openstack.org/bobcat/schedule.html | 14:02 |
| ralonsoh | This is the election week | 14:02 |
| ralonsoh | but, at least for Neutron, the result is clear! | 14:02 |
| ralonsoh | and we have RC1 released | 14:03 |
| ralonsoh | along with the stable/2023.2 branch | 14:03 |
| slaweq | \o/ | 14:03 |
| mtomaska | \o\/o/ | 14:03 |
| lajoskatona | cool | 14:03 |
| ralonsoh | we are officially pushing code to Caracal right now | 14:03 |
| ralonsoh | so please, remember to make your backports to 2023.2 too, if needed | 14:03 |
| ralonsoh | last week, in advance, is the final release of the RC | 14:04 |
| ralonsoh | and, as any week, please check the openinfra channel | 14:04 |
| ralonsoh | #link https://openinfra.dev/live/#all-episodes | 14:04 |
| bcafarel | o/ | 14:04 |
| ralonsoh | any other heads-up? | 14:05 |
| ralonsoh | ok, let's jump to the next topic | 14:05 |
| ralonsoh | #topic bugs | 14:05 |
| ralonsoh | last week report is from mtomaska | 14:05 |
| ralonsoh | #link https://lists.openstack.org/pipermail/openstack-discuss/2023-September/035125.html | 14:05 |
| ralonsoh | we have some pending bugs to review, not assigned yet | 14:06 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2035168 | 14:06 |
| ralonsoh | I would lower the priority of this one | 14:06 |
| ralonsoh | it is interesting to remove these tables but not mandatory | 14:06 |
| mtomaska | sure it does not seem to be breaking anything | 14:07 |
| ralonsoh | I think this is a low-hanging-fruit for anyone "playing" witht the DB migrations | 14:07 |
| lajoskatona | is there a gain if we remove? speed, complexity... ? | 14:07 |
| ralonsoh | nothing, to be honest | 14:07 |
| ralonsoh | these tables are not consuming resources | 14:08 |
| mtomaska | less testing. Maybe I should take a look how long those tests take? | 14:08 |
| lajoskatona | ok, so really low hanging fruit | 14:08 |
| SvenKieske | deleted code is good code ;) | 14:08 |
| lajoskatona | :-) | 14:08 |
| ralonsoh | no no, this is not deleting code but adding new migrations | 14:08 |
| ralonsoh | ok, next one | 14:08 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2035578 | 14:08 |
| ralonsoh | I will ping eolivare to know if he's on this one | 14:09 |
| ralonsoh | this one seems to be related to the zuul configuration | 14:09 |
| lajoskatona | he left comments on it | 14:09 |
| ralonsoh | yes | 14:09 |
| ralonsoh | I think they will need to have different zuul configs per stable branch | 14:09 |
| ralonsoh | same as other projects | 14:09 |
| ralonsoh | to add the supported (or not) OS and nodes to the branches | 14:10 |
| ralonsoh | I'll ping him after this meeting | 14:10 |
| ralonsoh | next one | 14:10 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2035230 | 14:10 |
| ralonsoh | IMO, what is happening is that they are creating a port in a network without subnets | 14:11 |
| ralonsoh | that matches with this output | 14:11 |
| ralonsoh | but we need more feedback. Just the port creation API result is not enough here | 14:11 |
| ralonsoh | in any case, any other review of this problem is always welcome | 14:12 |
| ralonsoh | ok, next one | 14:13 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2035573 | 14:13 |
| ralonsoh | I've closed this one as duplicated of LP#2016198 | 14:13 |
| ralonsoh | the problem: the fix for ^^ implies a DB migration | 14:13 |
| ralonsoh | so we can't backport it | 14:14 |
| ralonsoh | the problem is that if you send multiple HA network creation at the same time, there is a chance of race condition | 14:14 |
| ralonsoh | that leads to the creation (try to) create 2 HA networks | 14:14 |
| ralonsoh | the fix: create the network and the HAnetwork register in the same DB transaction | 14:15 |
| ralonsoh | that guarantees the isolation | 14:15 |
| ralonsoh | in any case, please review this one just to be sure I'm right (or not) in my conclusion | 14:15 |
| ralonsoh | last one | 14:16 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2035332 | 14:16 |
| ralonsoh | a "persistent" issue with OVN+DVR+VLAN networks | 14:16 |
| ralonsoh | slaweq, if I'm not wrong, we are going to block that but in some conditions | 14:17 |
| ralonsoh | when using port forwarding, right? | 14:17 |
| ralonsoh | I'll check this week if the LRP options the bug is describing are correct | 14:18 |
| ralonsoh | it is complicated the support matrix of redirect-type, reside-on-redirect-chassis and network types | 14:18 |
| slaweq | only when FIP PF are also enabled | 14:18 |
| ralonsoh | but I think this folk is misunderstanding the concepts here | 14:19 |
| slaweq | https://review.opendev.org/c/openstack/neutron/+/892542 | 14:19 |
| ralonsoh | "My understanding is that `reside-on-redirect-chassis` is to force traffic to the gateway rather then DVR this should be `True` as Vlan networks will need to go through the chassis gateway for everything where geneve DVR can have this as false to allow for DVR." | 14:19 |
| ralonsoh | ^ yes, this one | 14:19 |
| ralonsoh | anyway, I'll talk to ltombaso to check if the bug description is correct or there is any misundertanding on how OVN FIP works with VLAN networks | 14:21 |
| ralonsoh | I don't have any other bug in this list | 14:21 |
| ralonsoh | do you have any other pending bug? | 14:21 |
| opendevreview | Merged openstack/neutron master: Imported Translations from Zanata https://review.opendev.org/c/openstack/neutron/+/895526 | 14:22 |
| aprats- | I don´t know if it is the right time to ask, I'm looking for reviews on this one https://bugs.launchpad.net/neutron/+bug/2029722 | 14:22 |
| ralonsoh | this one seems to be assigned and a patch submitted | 14:23 |
| ralonsoh | if the bug is triaged, let's discuss it an the end of the meeting | 14:23 |
| ralonsoh | in the on_demand section | 14:23 |
| ralonsoh | This week bcafarel is the deputy, next week will be lajoskatona. | 14:23 |
| ralonsoh | akc? | 14:23 |
| lajoskatona | ack | 14:23 |
| ralonsoh | ack? | 14:23 |
| bcafarel | :) ack | 14:24 |
| ralonsoh | thanks | 14:24 |
| ralonsoh | #topic specs | 14:24 |
| ralonsoh | because we are starting a new release (while closing the last one) | 14:24 |
| ralonsoh | let's start reviewing the pending specs | 14:24 |
| ralonsoh | #link https://review.opendev.org/q/project:openstack%252Fneutron-specs+status:open | 14:24 |
| ralonsoh | we have "Add spec for partial support for OVN Interconnect RFE" on the plate | 14:25 |
| ralonsoh | please let's continue with the revision efforts from the last release | 14:25 |
| ralonsoh | ok, let's jump to the next topic | 14:26 |
| ralonsoh | #topic community_goals | 14:26 |
| ralonsoh | I'll skip the first one, "Add support for the service role in neutron API policies" | 14:26 |
| ralonsoh | 2) Neutron client deprecation | 14:26 |
| ralonsoh | lajoskatona, any update? | 14:26 |
| lajoskatona | nothing since last week | 14:26 |
| lajoskatona | The pending patches to neutronclient were merged | 14:27 |
| lajoskatona | I have to jump into this topic and allocate some time to it | 14:27 |
| lajoskatona | that's it | 14:27 |
| ralonsoh | perfect, I'll remove them from the meeting logs | 14:27 |
| ralonsoh | lajoskatona, thanks a lot | 14:27 |
| ralonsoh | ok, last section | 14:27 |
| ralonsoh | #topic on_demand | 14:27 |
| ralonsoh | aprats-, please | 14:28 |
| ralonsoh | aprats-, I think you wanted to talk about https://bugs.launchpad.net/neutron/+bug/2029722 | 14:29 |
| aprats- | Thx, pushed here https://review.opendev.org/c/openstack/neutron/+/890459, I just wanted to know what to do next so I can have this change merged :) | 14:29 |
| lajoskatona | coming to IRC and advertising it is a good step :-) | 14:29 |
| mlavalle | yes! | 14:29 |
| ralonsoh | so if I'm not wrong, what you want is to have multiple nating | 14:30 |
| ralonsoh | from https://launchpadlibrarian.net/680342877/Screenshot%20from%202023-08-02%2009-30-17.png | 14:30 |
| ralonsoh | subnet B - subnet A - internet | 14:30 |
| ralonsoh | right? | 14:30 |
| aprats- | Only router-ext is natting | 14:30 |
| ralonsoh | why not router LAN? | 14:31 |
| aprats- | But yes, I want to have the subnet B to be able to use the nat of subnet A (If that make sense) | 14:31 |
| aprats- | Some of our clients wanted to make some kind of DMZ with the subnet A | 14:31 |
| ralonsoh | I think you'll need to add routes inside the VM to access to the subnet A interface | 14:32 |
| ralonsoh | and from there, access the external GW | 14:33 |
| ralonsoh | but if router LAN is nating between two internal networks, that won't add any default GW | 14:33 |
| aprats- | Yes but it won't work, that's why I submitted this PR. We have a rule on the dvr that will only route traffic from directly attached networks | 14:34 |
| ralonsoh | yes because this is the goal of the router for internal networks | 14:34 |
| ralonsoh | the router won't egress any traffic via subnet A as a external network | 14:35 |
| ralonsoh | unless, maybe, you mark IP 10.20.0.1 (router ext, subnet A) as GW of the VMs | 14:35 |
| ralonsoh | did you try that? | 14:36 |
| aprats- | Just to be clear, adding 0.0.0.0/0 via 10.20.0.1 on the router lan routes will solve the routing issue from test_lan to the router_ext | 14:36 |
| ralonsoh | exactly | 14:36 |
| ralonsoh | so what's the problem then? | 14:37 |
| aprats- | Then there is still an issue, router_ext dvr won´t nat subnet B traffic | 14:37 |
| aprats- | And that's this behavior that my code fixes | 14:37 |
| ralonsoh | the problem is that your patch is adding snat to a router between internal networks | 14:38 |
| ralonsoh | and that is not how it should work | 14:39 |
| ralonsoh | actually you are adding this in the DVR router namespace only... | 14:39 |
| ralonsoh | (sorry) | 14:40 |
| ralonsoh | aprats-, I'm not sure about this code (and the lack of testing). I would need to deploy an environment to test it first, just to know that we don't introduce any strange backdoor there | 14:41 |
| aprats- | From my point of view i'm not adding snat capabilities to an privte to private router. I'm whitelisting linked networks to use an actual snat | 14:41 |
| ralonsoh | just one last question (we can discuss this offline) | 14:42 |
| aprats- | Perhaps it needs more testing, perhaps it's not not in the right place (I'm fairly new here) and i'm willing to learn :) | 14:42 |
| ralonsoh | how a router between two private network will have a GW? | 14:42 |
| aprats- | It has not | 14:43 |
| ralonsoh | if self._get_gw_ips_cidr(): # Check if router has a gateway | 14:43 |
| aprats- | This code impact router_ext not router_lan | 14:43 |
| ralonsoh | ok, as I said, I'll need manual testing (and better description and documentation in this patch) | 14:44 |
| haleyb | sorry, am in another meeting, but i think it's a valid bug, but like aprats- mentioned, it seems there is a cleaner place to put this i just don't see it yet | 14:44 |
| haleyb | but we can follow-up in the patch | 14:44 |
| aprats- | What it does is that it lists routes on a external router and will allow networks routed to use the external gateway | 14:44 |
| haleyb | s/routes/rules from what i remember right? | 14:45 |
| ralonsoh | let's continue that in the patch | 14:45 |
| haleyb | ack | 14:45 |
| aprats- | ack | 14:45 |
| ralonsoh | any other topic? | 14:45 |
| haleyb | i had a quick one | 14:45 |
| ralonsoh | please | 14:46 |
| haleyb | now that 2024.1 is open, i did two patches for testing updates | 14:46 |
| haleyb | https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/895516 to add 2023.2 tempest jobs | 14:46 |
| haleyb | https://review.opendev.org/c/openstack/neutron/+/895515 for adding SLURP jobs | 14:47 |
| haleyb | any reviews would be great | 14:47 |
| frickler | note that devstack and grenade aren't ready yet for 2023.2 | 14:47 |
| ralonsoh | right, this is the second SLURP release | 14:47 |
| lajoskatona | frickler: thanks for the info | 14:48 |
| haleyb | frickler: so do you mean i can't checkout stable/2023.2 in devstack and install? haven't looked actually | 14:49 |
| frickler | there is no branch yet | 14:49 |
| frickler | waiting for nova and requirements repos to branch | 14:49 |
| frickler | nova should hopefully get done later today | 14:50 |
| slaweq | haleyb thx, I just commented in Your patch for neutron-tempest-plugin | 14:51 |
| ralonsoh | but for now, the Neutron patch is valid and can be merged (I left a comment) | 14:51 |
| haleyb | right, i figured after some time we could make it voting, will need to update CI dashboard | 14:51 |
| ralonsoh | ok, any other topic | 14:52 |
| ralonsoh | please remember that today there won't be CI meeting | 14:52 |
| mlavalle | yeap | 14:52 |
| ralonsoh | but if you have something urgent, you can ping anyone here in this channel | 14:52 |
| ralonsoh | thank you for attending | 14:53 |
| ralonsoh | #endmeeting | 14:53 |
| opendevmeet | Meeting ended Tue Sep 19 14:53:13 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:53 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/networking/2023/networking.2023-09-19-14.01.html | 14:53 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/networking/2023/networking.2023-09-19-14.01.txt | 14:53 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/networking/2023/networking.2023-09-19-14.01.log.html | 14:53 |
| mlavalle | o/ | 14:53 |
| slaweq | o/ | 14:53 |
| lajoskatona | o/ | 14:53 |
| bcafarel | o/ | 14:54 |
| haleyb | o/ | 14:54 |
| frickler | ykarel|away: ralonsoh: could you please check https://bugs.launchpad.net/neutron/+bug/2031526 ? iiuc it should be resolved | 14:55 |
| ralonsoh | yes, it is | 14:56 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP test pep8 https://review.opendev.org/c/openstack/neutron/+/895821 | 15:08 |
| opendevreview | Miro Tomaska proposed openstack/neutron master: OVN Metadata handle process execeptions https://review.opendev.org/c/openstack/neutron/+/890986 | 15:12 |
| opendevreview | Brian Haley proposed openstack/neutron-tempest-plugin master: Add job definitions for 2023.2 (Bobcat) branch https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/895516 | 15:14 |
| opendevreview | Andrew Bogott proposed openstack/neutron-tempest-plugin master: Allow updating of address pair on shared network https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/890248 | 15:19 |
| opendevreview | Bodo Petermann proposed openstack/neutron-vpnaas master: Support for libreswan 4 https://review.opendev.org/c/openstack/neutron-vpnaas/+/895824 | 15:42 |
| opendevreview | Bodo Petermann proposed openstack/neutron-vpnaas master: Support for libreswan 4 https://review.opendev.org/c/openstack/neutron-vpnaas/+/895824 | 15:43 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: Check multiple address of a LRP plugged to LS https://review.opendev.org/c/openstack/ovn-octavia-provider/+/895826 | 16:01 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: Check multiple address of a LRP plugged to LS https://review.opendev.org/c/openstack/ovn-octavia-provider/+/895826 | 16:31 |
| opendevreview | Brian Haley proposed openstack/neutron master: Remove obsolete radvd PID files before start https://review.opendev.org/c/openstack/neutron/+/895832 | 17:30 |
| opendevreview | Brian Haley proposed openstack/neutron master: Bump skip-level lower version to stable/2023.1 https://review.opendev.org/c/openstack/neutron/+/895515 | 17:30 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: functional: Use OVN version v22.06.1 https://review.opendev.org/c/openstack/neutron/+/895849 | 19:03 |
| opendevreview | Miro Tomaska proposed openstack/neutron master: OVN Metadata handle process execeptions https://review.opendev.org/c/openstack/neutron/+/890986 | 19:25 |
| opendevreview | Miro Tomaska proposed openstack/neutron master: OVN Metadata handle process execeptions https://review.opendev.org/c/openstack/neutron/+/890986 | 19:33 |
| opendevreview | Brian Haley proposed openstack/neutron master: Remove obsolete radvd PID files before start https://review.opendev.org/c/openstack/neutron/+/895832 | 19:36 |
| opendevreview | Merged openstack/neutron master: Open the 2024.1 (Caracal) DB branch https://review.opendev.org/c/openstack/neutron/+/895155 | 20:24 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
