February 2024 - openstack-discuss

[openstack-helm] Ceph-osd + Jammy + loop device is broken now
by Vladimir Kozhukalov 13 Feb '24

13 Feb '24

Hi team, Due to this [1] some of our test jobs which utilize the ceph-osd chart and which run on Ubuntu Jammy are broken now. Recent changes in ioctl are incompatible with parted when used with loop devices. Ceph-osd chart uses parted in the osd init script. So it does not work now with the error like this ``` Error: Partition(s) 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64 on /dev/loop100 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes. ``` The issue appears only on Ubuntu Jammy. My suggestion is to temporarily disable the 2023.2 TLS job which is broken now. And to use the 2023.1 TLS job on Focal. Please review https://review.opendev.org/c/openstack/openstack-helm/+/908947 [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2049689 -- Best regards, Kozhukalov Vladimir

1 0

[openstack-ansible] Bug fighting day
by Dmitriy Rabotyagov 13 Feb '24

13 Feb '24

Hey everyone. During the previous meeting we decided that it might be a good idea to take a couple hours together to work on the project bug tracker [1]. We are going to focus on closing irrelevant bugs that were issued towards EOLed releases and do not apply to any supported code or were already fixed. Along with that we will try to triage and prioritize ones that are still relevant and need some attention. In order to decide on the date/time when this activity will take place I have created a poll [2]. It will be open till Sunday, Feb 11. Everyone who is willing to help us is very welcome to join the poll. If you have an outstanding bug that somehow slipped our attention - this is really a good chance to bring it up to the team as well. [1] https://bugs.launchpad.net/openstack-ansible [2] https://doodle.com/meeting/organize/id/enGV50Wa

1 2

http://apps.openstack.org/#tab=murano-apps unavailable
by Karera Tony 13 Feb '24

13 Feb '24

I have deployed Murano in my environment, However when I tried to get the application budle following the Murano guide from http://apps.openstack.org/#tab=murano-apps. I realized that the site is down. Is there an alternative ? Regards Regards Tony Karera

2 1

[nova]: openstack-ansible Ussuri - rabbitmq connection distribution
by keshav bareja 13 Feb '24

13 Feb '24

2 1

[magnum] Weekly meeting (14/Feb/2024) cancelled
by Michał Nasiadka 13 Feb '24

13 Feb '24

Hello, Due to absence of key team members - the weekly meeting tomorrow (14/Feb/2024) is cancelled. See you next week! Best regards, Michal

1 0

[all][tc] OpenStack 2024.2 testing runtime
by Ghanshyam Mann 12 Feb '24

12 Feb '24

Hi All, Its time to deifne the testing runtime for next cycle 2024.2. I have proposed it in gerrit, feel free to review/feedback there. - https://review.opendev.org/c/openstack/governance/+/908862 Changes from previous cycle testing runtime for quick ref: * Removing python 3.8 support because it is EOLing in oct 2024[1] which means python 3.9 will be the minimum python version in testing runtime. * Remove Debian 11 from Additional testing support because 2024.2 is non-SLURP release and previous SLURP release 2024.1 supported Debian 12 also which is what can be used as smooth upgrade to future SLURP release 2025.1 * Removing Nodejs from runtime: Nodejs is not a runtime requirement for Horizon instead it is one of the test dependency. It does not fit as a runtime and can be handle by Horizon team based. Added Horizon team to review this change. -gmann

1 0

[neutron][vpnaas][ovn] Pushing VPNaaS support through OVN
by Mohammed Naser 12 Feb '24

12 Feb '24

Hi all! One of the biggest show stoppers for us for OVN is VPNaaS but I think it’s time that we’d like to be involved in getting it over the line, I want to thank Bodo who has shown a lot of patience in getting the code necessary, and it seems that the code works for them in production as well. I’d like to ask if possible for folks to review these two outstanding changes: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/847007 https://review.opendev.org/c/openstack/neutron-vpnaas/+/765353 I know Slawek had some concerns, so hoping that raising via the email list if Bodo can address those and over the next bit of time we can get this landed in, since it even has actual proper testing both in CI and with user feedback. Thanks! Mohammed

6 8

[neutron] Bugs deputy report February 5th to 11th
by Rodolfo Alonso Hernandez 12 Feb '24

12 Feb '24

Hello all: This is the bug list from the past week: Critical ======================== https://bugs.launchpad.net/neutron/+bug/2052509. "[CI][ovs/ovn sqlalchemy master] jobs broken with Exception: Not enough arguments given". Assigned. Patch: https://review.opendev.org/c/openstack/devstack/+/908572 https://bugs.launchpad.net/neutron/+bug/2052787. "SSH timeouts due to problems with metadata server in ML2/OVN backend". Assigned. High ======================== https://bugs.launchpad.net/neutron/+bug/2052628. "[stable-only][ovn-octavia-provider] Multiple listener-pool-member on IPv6 LB getting second pool in ERROR". Assigned. Patch: https://review.opendev.org/q/I37e660d5eaa45deb38ff127cf69195b0a9ef0846 (merged). Medium ======================== https://bugs.launchpad.net/neutron/+bug/2052484. "[DEFAULT] rpc_worker=0 leaves one rpc worker". Assigned. Patch: https://review.opendev.org/c/openstack/neutron/+/908173 https://bugs.launchpad.net/neutron/+bug/2052681. " Many stale neutron-keepalived-state-change processes left after upgrade to native pyroute2 state-change". Not assigned. https://bugs.launchpad.net/neutron/+bug/2052821. "[OVN] Pin a Logical_Router to a chassis when the external network is tunnelled". Assigned. https://bugs.launchpad.net/neutron/+bug/2052843. "[OVN Octavia Provider] subnet with multiple router gateways lb association". Assigned. Patch: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/908679 https://bugs.launchpad.net/neutron/+bug/2052419. "SG list retrieval is slow because we are always loading "synthetic_fields"". Assigned. Patches: https://review.opendev.org/q/I300464472f2348d148f2a3ddac384c883d9d815b Low ======================== https://bugs.launchpad.net/neutron/+bug/2052508. " [doc][troubleshooting] how to enable ovs vswitchd debug logs". Not assigned. https://bugs.launchpad.net/neutron/+bug/2052786. " Add "socket" to NUMA affinity policy". Assigned. Patch: https://review.opendev.org/c/openstack/neutron-lib/+/903531 Regards.

1 0

PTG April 2024 Team Signup Deadline Approaching!
by Kendall Nelson 11 Feb '24

11 Feb '24

Hello Everyone, This is your *last call *to sign up your team up for the next Project Teams Gathering (PTG)[1], which will be held from Monday, April 8 to Friday, April 12 2024! If you haven't already done so and your team is interested in participating, *you need to complete the survey[2] by February 18, 2024 at 7:00 UTC*. Thanks! -Kendall Nelson (diablo_rojo) [1] PTG Site: https://openinfra.dev/ptg/ [2] Team Survey: https://openinfrafoundation.formstack.com/forms/april2024_ptg_survey

1 0

[openstack-ansible] [kolla-ansible] 2023.1 Antelope - In series upgrade - All/few neutron agents dead
by Shrishail K 11 Feb '24

11 Feb '24

Hi Team, I would like to seek some help regarding the issue I am facing while performing in series upgrade on the Antelope version. We have currently deployed our cluster with *2023.1 Antelope *version. The cluster was deployed on a clean environment by cleaning up any previous kolla openstack installation. We have not observed any issues with this environment so far. For a feature I am working on, I had to *put a patch into GLANCE image* and rebuild all *kolla images with a new tag*. I have attempted to upgrade the cluster using both *kolla-deploy *and *kolla-upgrade *methods, but both methods have left the *cluster in degraded condition*. The issue seems to be mainly with failure of communication between *neutron-server *and all/some *neutron-agents, *due to which the neutron-server sees *all/some* *neutron-agents dead*. *Rabbitmq *itself seems to be doing fine. The issue is very consistent. Is this a known behavior? And am I using the correct kolla tools to perform the in series upgrade. Appreciate any help. Thanks, Shrishail

1 0