- openstack-discuss - lists.openstack.org

[nova][ci] cyborg-tempest (non-voting) job is failing
by melanie witt 09 Sep '24

09 Sep '24

Hey everyone, I noticed that the cyborg-tempest (non-voting) CI job began failing on the master branch sometime on 2024-09-03: https://zuul.opendev.org/t/openstack/builds?job_name=cyborg-tempest&project… The errors I see in the test result report are policy related, for example: Details: {'error_message': '{"faultcode": "Server", "faultstring": "\\"cyborg:device_profile:create\\": \\"rule:system_admin_api\\" requires a scope of [\'system\'], request was made with project scope.", "debuginfo": null}'} I'm guessing this is related to the recent "oslo.policy 4.4.0 enable the RBAC new defaults by default" change [1]: https://review.opendev.org/c/openstack/requirements/+/925464 The job is non-voting so it's not blocking anything, but it would be great if someone knows the best way to fix it. -melwitt [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

2 1

Request objects
by engineer2024 08 Sep '24

08 Sep '24

How long do nova request objects live when a user request comes in ? Do they persist until the result is returned by the server ? Please throw some light on this... Thanks

1 0

[openstack][glance] Cannot rescue instance if image boot was deleted
by Nguyễn Hữu Khôi 08 Sep '24

08 Sep '24

Hi folks, I have this problem, It is glad if I had some guides for this situation. Openstack Version: 2023.1 OS: Ubuntu 22.04 Deployment Tool: Kolla-Ansible When I try to rescue an instance that booted from a volume, I cannot do so if the image used for the volume boot has been deleted This is an error message: Instance 6deeed71-c701-42a3-a8f9-d89048a47c11 cannot be rescued: Driver Error: Block Device Mapping is Invalid: failed to get image 844ea429-23a5-43d4-8f65-19c879d63921. Thank you. Nguyen Huu Khoi

4 6

Using diskimage-creator for vhd format
by Tony Lombardo 06 Sep '24

06 Sep '24

Hi all. As an example I was trying to run something like this command: sudo tox -e venv -- disk-image-create -o ubuntu-min-gold.vhd vm block-device-gpt ubuntu-minimal -t vhd However, I do get the error message that vhd-util isn't available. "vhd output format specified but no vhd-util executable found." I read the commit where this was deprecated in favor of qemu-img https://opendev.org/openstack/diskimage-builder/commit/a3e9e7f89e1059ae0929… I can't seem to get the syntax for the command to work, not sure what I am missing but any help would be greatly appreciated. QEMU emulator version 6.2.0 Diskimage-builder 3.33.1 I'm running this in WSL Ubuntu, it seems to work. I was able to create an image - just not the vhd format I need. Thanks in advance for any advice. -Tony -- Tony Lombardo Systems Administrator Division of Public Safety Access Control Department Cornell University

4 5

Struggling to rejion a node into rabbitmq cluster of Openstack-on-Ansible environment
by sudeb ghosh 06 Sep '24

06 Sep '24

Hi Team, We are operating an OpenStack environment managed by Ansible with 3 controller nodes. Openstack Version: Ussuri(21.2.1) OS: CentOS8 Recently, Controller-2 encountered a network partition with rabbitmq cluster issue that we couldn't resolve, leading us to remove it from the rabbitmq cluster and do rabbitmqctl reset. Since then, the RabbitMQ cluster node removal, We are currently unable to rejoin this node to the RabbitMQ cluster. The following error occurs when attempting to join the cluster: [Controller-2]# rabbitmqctl join_cluster rabbit@ctrl-1-rabbit-mq-container Clustering node rabbit@ctrl-2 with rabbit@ctrl-1 Error: {:failed_to_cluster_with, [:"rabbit@ctrl-3", :"rabbit@ctrl-1"], 'Mnesia could not connect to any nodes.'} We have verified that Controller-2 can communicate with other nodes in the cluster and it responds with a 'pong' for "rabbitmqctl eval 'net_adm:ping('\''rrabbit@ctrl-1'\'').'" There are no additional error logs indicating the root of the problem. We would appreciate any assistance in resolving this issue. Regards, Sudeb Ghosh 7044064878 9332034788

2 1

[all][tc][ptls] Eventlet: Python 3.13 - Attach your seatbelt
by Herve Beraud 06 Sep '24

06 Sep '24

Hi all, As Python 3.13 is close to become a reality, new concerning incompatibilities between this new CPython version and Eventlet also become a reality: - https://github.com/eventlet/eventlet/issues/964 Fedora Python maintainers proposed a patch, but for now the problem remains unsolved. Also, many people reported bugs related to incompatibility between python3.12/dnspython/eventlet/pip-system-cert. There is an example who summarize well the problem https://github.com/eventlet/eventlet/issues/957 Do you have some visibility concerning the adoption of Python 3.13 into Openstack? Turbulences ahead... -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

4 5

[release] Release countdown for week R-3, Sep 09-13
by Elõd Illés 06 Sep '24

06 Sep '24

Development Focus ----------------- The Release Candidate (RC) deadline is next Friday, September 13th, 2024. Work should be focused on fixing any release-critical bugs. General Information ------------------- All deliverables released under a cycle-with-rc model should have a first release candidate by the end of the week, from which a stable/2024.2 branch will be cut. This branch will track the 2024.2 Dalmatian release. Once stable/2024.2 has been created, the master branch will be ready to switch to 2025.1 Epoxy development. While the master branch will no longer be feature-frozen, please prioritize any work necessary for completing 2024.2 Dalmatian plans. Release-critical bugfixes will need to be merged in the master branch first, then backported to the stable/2024.2 branch before a new release candidate can be proposed. Actions ------- Early in the week, the release team will be proposing RC1 patches for all cycle-with-rc projects, using the latest commit from the master branch. If your team is ready to go for cutting RC1, please let us know by leaving a +1 on these patches. If there are still a few more patches needed before RC1, you can -1 the patch and update it later in the week with the new commit hash you would like to use. Remember, stable/2024.2 branches will be created with this, so you will want to make sure you have what you need included to avoid needing to backport changes from the master branch (which will technically then be 2025.1 Epoxy) to this stable branch for any additional RCs before the final release. The release team will also be proposing releases for any deliverable following a cycle-with-intermediary model that has not produced any 2024.2 Dalmatian release so far. Finally, now is a good time to finalize release highlights. Release highlights help shape the messaging around the release and make sure that your work is properly represented. Upcoming Deadlines & Dates -------------------------- RC1 deadline: September 13th, 2024 (R-3 week) Final RC deadline: September 26th, 2024 (R-1 week) Final 2024.2 Dalmatian release: October 2nd, 2024 Előd Illés irc: elodilles @ #openstack-release

1 0

[releases][tempest] Tempest 39.1.0 release
by Rodolfo Alonso Hernandez 05 Sep '24

05 Sep '24

Hello all: Because I think I'm having some communication problems about [1], I would like to write it down in a mail. This release patch for 2024.2 is pointing to [2]. However, the requirements branch used in tempest was tagged as 2024.1. That means the tempest release for 2024.2 will use the requirements from 2024.1. There are other examples done in previous releases that support what I'm saying: * 2023.2: ** https://review.opendev.org/c/openstack/releases/+/896158 ** https://github.com/openstack/tempest/commit/3926608631111a0ec93b3c44129d0cb… * 2023.1: ** https://review.opendev.org/c/openstack/releases/+/877840 ** https://github.com/openstack/tempest/commit/7c7d0fdd67022ad48ed128c997dfcc3… BTW, despite not having the stable 2024.2 branch in "requirements", the link https://releases.openstack.org/constraints/upper/2024.2 is valid and points to master (once the stable branch is created, that will point to 2024.2). Regards. [1]https://review.opendev.org/c/openstack/releases/+/927833 [2]https://review.opendev.org/c/openstack/tempest/+/927831

2 2

[manila] Dalmatian bugsquash - Sep 9th - 10th
by Carlos Silva 05 Sep '24

05 Sep '24

Hello, Zorillas and interested stackers! We'll have the second bugsquash of the Dalmatian cycle next week. As we have agreed a couple of weeks ago, it will be a two day event (Sep 9 and 10th). We will have a kick-off meeting on Monday, 15 UTC and we will use a meetpad [1] for the meeting. We will be focusing on bugs that are in progress and try to get them delivered as part of the 2024.2 Dalmatian release. Please check the ethercalc with the list of bugs [2] and add the bug you are willing to work on over the next week if it is not there yet. I'm looking forward to it :) [1] https://meetpad.opendev.org/manila-dalmatian-m3-bugsquash [2] https://ethercalc.net/mgstvday5vq0 Regards, carloss

1 0

FIPs broken when used with tunneled router gateway networks
by Sesterhenn, Maximilian 05 Sep '24

05 Sep '24

Hey all, I am currently facing an issue with OpenStack Neutron and OVN and could need some help here. Maybe someone else is doing something similar and can report if it works for them. TLDR: FIPs are broken for us when used together with routers which use a tunneled network as router gateway network. ovn_router_indirect_snat is not used and both OVN 23.09 and 24.03 have been tested. FIPs work fine when used with an external provider network. We have deployed three OpenStack projects, let's just call the left, middle and right for simplicity. The middle project has a network with a large subnet. No special configuration here, just a big subnet which is transported by OVN through Geneve. The idea is to use this subnet as an internal transfer network between different projects / tenants, which means we connect routers with SNAT and FIP configuration. Left and right are potentially the same subnet, that's why we cannot simply route the traffic. The network is shared with "access_as_external/shared" RBAC rules with both the left and right tenant, so it can be selected as the external gateway network for routers. I'm aware that until very recently, neutron was unable to assign a chassis to routers which use gateway networks which are tunneled. Thats why we are currently running the latest neutron code from the master branch where this feature was added. Let's say we want to connect from left to right and we have a router in each project that has this large network from the middle project as the external gateway network. An instance in the right tenant has a FIP to be reachable. Another instance in the left tenant is masqueraded by the SNAT functionality of the router. The router in the left project performs SNAT and the router in the right project performs the FIP DNAT. While the instance from the left project can ping the internal and external interfaces of its local router, the FIP is not reachable. The external interface of the remote router (from the right project) can be pinged as well. When capturing packets on the underlying hosts we can see the packet going from the compute host of the left instance to one of the network nodes. SNAT happens there, DNAT is not visible, this could be due to the packet capture scenario. However, we see ARP requests coming from the external interface of the router on the right project for the FIP address. We see the same ARP requests on a second network node. To me it would make more sense if the router from the left project would ARP for the FIP address. This ARP request is not being answered. We're using enable_distributed_floating_ip / DVR, so the FIP is actually configured onto the compute node. We're not using ovn_router_indirect_snat, here are issues with that. We even tried that; it makes no difference. OVN 23.09 (tested 24.03 as well) OpenStack 2024.1 (neutron master) deployed using kolla-ansible. BR Maximilian

2 2