| opendevreview | Rico Lin proposed openstack/neutron master: [OVN] Mark agents down when Chassis is deleted but Chassis_Private remains https://review.opendev.org/c/openstack/neutron/+/984495 | 00:44 |
|---|---|---|
| opendevreview | Brian Haley proposed openstack/ovn-octavia-provider master: Use project_id in all test code https://review.opendev.org/c/openstack/ovn-octavia-provider/+/985743 | 02:33 |
| opendevreview | Helen Chen proposed openstack/neutron-specs master: Propose spec for BGP EVPN Type-5 Route Support https://review.opendev.org/c/openstack/neutron-specs/+/982256 | 04:28 |
| cardoe | haleyb: During the Ironic/Neutron cross session I was talking about "cost" of connectivity as well as saying that VXLAN VNI 20000 might have multiple uses / meanings and the fact that Neutron has 1 pool of VNIs unlike VLANs where there's a pool per physical_network (which is what the spec I'm gonna update covers)... Well now that I see Helen's spec above... https://review.opendev.org/c/openstack/neutron-specs/+/982256 | 05:59 |
| cardoe | That's literally the case. | 05:59 |
| cardoe | So her second picture shows what I was talking about "cost" wise.. Machines can live on the left or the right. Let's say nova is asked to build 2 servers and it randomly picks them left and right, that's the "costly" option. But if it built them both on one side or the other then its "cheaper". | 06:01 |
| cardoe | The other part about the extra pools. Well there's "evpn_vni_auto_ranges" which is adding another VNI pool to neutron but hardcoding it to just 1 more. You | 06:08 |
| cardoe | You'll get other asks for more pools in the future. | 06:08 |
| cardoe | And maybe abusing network-segment-range isn't correct for a pool | 06:35 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Pass ``external_ids`` in the ``address_set_add`` command https://review.opendev.org/c/openstack/neutron/+/977923 | 08:24 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: Update all authentication algorithms to be sha256 https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/985774 | 08:40 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-vpnaas master: Remove deprecated sha1, md5, and des algorithm references https://review.opendev.org/c/openstack/neutron-vpnaas/+/982383 | 08:50 |
| opendevreview | Adam Harwell proposed openstack/neutron master: Fix unbounded thread pool in OVN MaintenanceThread https://review.opendev.org/c/openstack/neutron/+/985722 | 08:58 |
| rm_work[m] | ralonsoh: ^^ addressed, ended up just using your test verbatim, seems good | 08:59 |
| ralonsoh | let me check | 09:04 |
| rm_work | No worries, not in a rush. We have an internal patching system so we’re good for now, will need to wait for backports too | 09:20 |
| ralonsoh | rm_work, unit test works fine, please fix the pep8 error: https://zuul.opendev.org/t/openstack/build/aafa48fdfd044dfa9081ca89c1c2d287 | 09:20 |
| rm_work | wtf I ran pep8 locally grrrrrr | 09:21 |
| opendevreview | Martin Morgenstern proposed openstack/neutron stable/2026.1: Add logging decorator for OVN maintenance methods https://review.opendev.org/c/openstack/neutron/+/985783 | 09:22 |
| opendevreview | Martin Morgenstern proposed openstack/neutron stable/2025.2: Add logging decorator for OVN maintenance methods https://review.opendev.org/c/openstack/neutron/+/985784 | 09:23 |
| opendevreview | Merged openstack/neutron-fwaas master: Start using context.project_id https://review.opendev.org/c/openstack/neutron-fwaas/+/984949 | 09:28 |
| opendevreview | Adam Harwell proposed openstack/neutron master: Fix unbounded thread pool in OVN MaintenanceThread https://review.opendev.org/c/openstack/neutron/+/985722 | 09:36 |
| rm_work[m] | weird, idk why my pep8 is not catching it locally, couldn't get a fail... but fixed according to the upstream zuul result /shrug | 09:46 |
| rm_work[m] | commented, happy to go with that current patch but wonder if maybe the thing opus suggested might be a good middle-ground to real testing vs determinism | 09:57 |
| opendevreview | Steve Traylen proposed openstack/python-neutronclient master: Remove redundant import of reno for docs https://review.opendev.org/c/openstack/python-neutronclient/+/985789 | 10:05 |
| opendevreview | Merged openstack/neutron-lib master: objects: Prepare for oslo.versionedobjects 3.10.0 https://review.opendev.org/c/openstack/neutron-lib/+/985636 | 10:57 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Reduce DB retry decorator retries to 1 in unit tests https://review.opendev.org/c/openstack/neutron-lib/+/985798 | 11:07 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Add security-groups-default-statefulness API definition https://review.opendev.org/c/openstack/neutron-lib/+/984354 | 11:07 |
| rm_work[m] | ralonsoh: you're ok with the test as-is (basically the one you wrote)? not concerned about noise? I guess AI could be wrong but it definitely SOUNDED legit :D who knows with this magic code slot-machines tho lol | 12:36 |
| rm_work[m] | i don't care so much about the test as long as you're happy with it, since my test is monitoring it in real usage for the last 24h and it has been perfect so far | 12:37 |
| ralonsoh | rm_work[m], I asked Claude to rewrite this test but I finally did it manually | 12:42 |
| rm_work[m] | haha yeah that ends up happening to me a lot too | 12:42 |
| lajoskatona | haleyb, all: the first topic for today is LFX insights, and when I today open the link (https://insights.linuxfoundation.org/project/OpenStack/repository-group/neutron) I have just this msg: "This project hasn't been onboarded to LFX Insights." | 12:43 |
| rm_work[m] | i still like it for brainstorming / research or sometimes just to get me started | 12:43 |
| lajoskatona | Last week I was happy with it (even sent to my managers), but seems it was improved in the last week :-) | 12:43 |
| rm_work[m] | well if in the future it starts behaving badly/flaky, the alternative test is in the comments of the CR | 12:43 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: Update all authentication algorithms to be sha256 https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/985774 | 12:48 |
| haleyb | lajoskatona: sigh, it was working the other day | 12:52 |
| haleyb | there is always stackalytics i guess for reference | 12:53 |
| lajoskatona | haleyb: I hope we have some working crystal ball | 12:54 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2026.1: Fix unbounded thread pool in OVN MaintenanceThread https://review.opendev.org/c/openstack/neutron/+/985815 | 13:02 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2025.2: Fix unbounded thread pool in OVN MaintenanceThread https://review.opendev.org/c/openstack/neutron/+/985816 | 13:02 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2025.1: Fix unbounded thread pool in OVN MaintenanceThread https://review.opendev.org/c/openstack/neutron/+/985817 | 13:02 |
| *** ykarel_ is now known as ykarel | 13:29 | |
| ykarel | ralonsoh, hi, in the call you mentioned something about process is changed regarding the movement to x/namespace , can you share more context about this? | 13:29 |
| ykarel | or link the document or mailing list where this is described | 13:30 |
| ralonsoh | #link https://review.opendev.org/c/openstack/neutron/+/982557 | 13:30 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/982557/2/neutron/extensions/stateful_security_group.py | 13:40 |
| ralonsoh | ykarel, let me check that later | 13:40 |
| ykarel | ack | 13:41 |
| stephenfin | haleyb: I see you're discussing neutronclient work at the moment. I'm in the nova room for the afternoon, but am available here if there's anything I can help me. I still need to get back to lajoskatona's patch but otherwise I think I'm on top of things. | 14:13 |
| stephenfin | *I can help with | 14:13 |
| haleyb | stephenfin: yes, it's next on the list, think it's mostly about the migration of things into OSC and osc plugin code into the client, i actually haven't looked at the second much myself | 14:15 |
| ralonsoh | ykarel, I'm trying to find it written somewhere. I had this conversation in the #openstack channel | 14:34 |
| ralonsoh | ykarel, from gemini: https://paste.opendev.org/show/bL9AO054QcmjedToD3Cd/. The only reference I found is https://review.opendev.org/c/openstack/project-config/+/847135 | 14:37 |
| ykarel | ralonsoh, i was mainly looking for some official doc or announcement, like i am reading https://github.com/openstack/governance/blob/e74fe14bbff38b87cd50f57a7d4efdadff860f7d/reference/dropping-projects.rst#id3 but not clear if x/ is still an option or not | 14:42 |
| ralonsoh | ykarel, yeah, I'm trying to find it too. The point is that /x namespace doesn't belong to openstack but to opendev | 14:43 |
| ralonsoh | I think this is the problem | 14:43 |
| stephenfin | ralonsoh: I don't have context, but fungi recently told me that the x/ namespace projects were exclusively for things that had no owner during the setup of opendev (I think that was it?) and new projects aren't allowed there (there's a job apparently). If there's a deliverable you require on living there, it should probably live elsewhere | 14:48 |
| stephenfin | You may already know all of that. If so, sorry for the noise! | 14:48 |
| ralonsoh | stephenfin, actually that was the topic: what to do with unattended projects | 14:49 |
| ralonsoh | I thought moving to /x was now forbidden, but I can be wrong | 14:49 |
| stephenfin | Is it a project that you (neutron) used to maintain that's no longer maintained, or a project that you simply depend on which no longer has a clear owner? | 14:51 |
| fungi | correct, we don't want to add any more repositories to the x/ namespace, but you can implicitly create a new namespace just by prepending a repository name with it | 14:53 |
| ralonsoh | fungi, ok, nice to know this! | 14:54 |
| ykarel | fungi, stephenfin thx that clears our doubts here, do we also document this somewhere? | 14:54 |
| fungi | we can also fairly easily (though not instantly) move repositories fro x/ to another namespace (new or existing) | 14:55 |
| fungi | https://docs.opendev.org/opendev/infra-manual/latest/creators.html#decide-status-and-namespace-of-your-project would be a good place to expand if it's unclear | 14:56 |
| lajoskatona | fungi, stephenfin, ralonsoh: an example from the past is networking-l2gw under x/ as I remember it was a Neutron stadium but when nobody maintained it, it was moved there, and it still lives there (I maintain it mostly when I have time or when it has some serious issue) | 14:58 |
| fungi | it could have just as easily moved to oldtron/networking-l2gw or something | 14:59 |
| lajoskatona | :-) | 15:00 |
| fungi | right after the openstack/ namespace eviction, we were still feeling things out. that was also before openstack instituted the mandatory retirement policy, i think | 15:01 |
| otherwiseguy | haleyb: on https://review.opendev.org/c/openstack/neutron-specs/+/983896/2/setup.py do we know why the #! line was removed? And since it is still marked as executable, is that an issue? | 15:17 |
| opendevreview | Merged openstack/neutron-specs master: Remove outdated comment in setup.py https://review.opendev.org/c/openstack/neutron-specs/+/983896 | 15:17 |
| haleyb | otherwiseguy: i guess it doesn't have to be executable, could do some git-fu and fix that i guess | 15:19 |
| otherwiseguy | haleyb: just didn't know if the globally managed part was linked to the removing #! part at all, or if it was a separate change. But in any case it seemed like executability and #! should be linked :) | 15:21 |
| otherwiseguy | I thought I had time to discuss while tests ran, but they were very quick :p | 15:22 |
| opendevreview | Brian Haley proposed openstack/neutron-specs master: Change mode of setup.py to 644 https://review.opendev.org/c/openstack/neutron-specs/+/985835 | 15:26 |
| haleyb | otherwiseguy: yeah, it merged quick, think was just to bring in-line with neutron. but ^^^ | 15:26 |
| haleyb | arg, and i can't type | 15:26 |
| opendevreview | Brian Haley proposed openstack/neutron-specs master: Change mode of setup.py to 664 https://review.opendev.org/c/openstack/neutron-specs/+/985835 | 15:26 |
| otherwiseguy | typing is overrated | 15:26 |
| haleyb | and i can't type again | 15:27 |
| haleyb | it's odd i used chmod 664 but change says mode 100644 so i'm confused | 15:27 |
| haleyb | whatever | 15:28 |
| otherwiseguy | haleyb: ai is telling me that the 100 prefix signifies "file type is a regular file" | 15:29 |
| otherwiseguy | and you can trust the computers implicitly, obviously. they mean us no harm. | 15:29 |
| haleyb | yeah, the fact it thinks it's 644 when it's not, well whatevs | 15:30 |
| haleyb | i've got my aluminum hat on now so skynet can't track me | 15:31 |
| opendevreview | Doug Goldstein proposed openstack/neutron master: allow physical_network to be set for provider networks on VXLAN https://review.opendev.org/c/openstack/neutron/+/985837 | 15:33 |
| opendevreview | Doug Goldstein proposed openstack/neutron master: allow physical_network to be set for provider networks on VXLAN https://review.opendev.org/c/openstack/neutron/+/985837 | 15:34 |
| cardoe | haleyb: yeah git uses some extra digits in front to carry other data about the file but that's a normal file | 15:35 |
| otherwiseguy | haleyb: when I check it out, it's 644 | 15:37 |
| haleyb | -rw-rw-r-- is what it shows in my copy, wtf | 15:38 |
| otherwiseguy | Weird. But when I check out w/o patch 755, w/ patch 644, which is at least consistent. Something w/ parent directory permissions or something? | 15:39 |
| haleyb | drwxrwxr-x | 15:39 |
| haleyb | i'll see if i can hack it to 664 | 15:40 |
| otherwiseguy | Looks like git only tracks executability | 15:40 |
| otherwiseguy | haleyb: so anything else will just be whatever you had. | 15:41 |
| haleyb | git only has two modes apparently, 755 and 644, as long as nothing breaks | 15:43 |
| ykarel | haleyb, can you revisit https://review.opendev.org/c/openstack/neutron/+/984364 | 15:58 |
| haleyb | ykarel: done | 16:07 |
| ykarel | thx haleyb | 16:07 |
| opendevreview | Brian Haley proposed openstack/neutron stable/2026.1: Ignore designate NotFound errors during PTR delete https://review.opendev.org/c/openstack/neutron/+/985850 | 17:06 |
| opendevreview | Brian Haley proposed openstack/neutron stable/2025.2: Ignore designate NotFound errors during PTR delete https://review.opendev.org/c/openstack/neutron/+/985851 | 17:06 |
| opendevreview | Brian Haley proposed openstack/neutron stable/2025.1: Ignore designate NotFound errors during PTR delete https://review.opendev.org/c/openstack/neutron/+/985852 | 17:07 |
| opendevreview | Brian Haley proposed openstack/neutron stable/2024.2: Ignore designate NotFound errors during PTR delete https://review.opendev.org/c/openstack/neutron/+/985853 | 17:08 |
| opendevreview | Brian Haley proposed openstack/neutron unmaintained/2024.1: Ignore designate NotFound errors during PTR delete https://review.opendev.org/c/openstack/neutron/+/985854 | 17:08 |
| opendevreview | Merged openstack/neutron master: [functional fips] Switch venv prep to python3.12 https://review.opendev.org/c/openstack/neutron/+/984364 | 18:10 |
| opendevreview | Brian Haley proposed openstack/neutron-tempest-plugin master: Use project_id key in api and scenario tests https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/982736 | 18:46 |
| opendevreview | Merged openstack/neutron master: Fix unbounded thread pool in OVN MaintenanceThread https://review.opendev.org/c/openstack/neutron/+/985722 | 20:11 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: bgp: Update main router policies when chassis is added https://review.opendev.org/c/openstack/neutron/+/985895 | 21:36 |
| opendevreview | Merged openstack/neutron master: Add documentation for BGP multinode tempest job https://review.opendev.org/c/openstack/neutron/+/984318 | 22:42 |
| opendevreview | Merged openstack/neutron master: Add Neutron mark to localnet ports https://review.opendev.org/c/openstack/neutron/+/984411 | 23:48 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!