- openstack-discuss - lists.openstack.org

[ironic] canceling meetings April 1st and April 8th
by Riccardo Pittau 25 Mar '24

25 Mar '24

Hello ironicers! We're canceling the ironic weekly meetings for the next 2 weeks: - April 1st is bank holiday in many countries in Europe and America and most of the cores won't be available - April 8th is the first day of the PTG Next meeting will be held on April 15th Ciao Riccardo

1 0

[tc] Next TC Meeting Tomorrow, March 26, 1800 UTC
by Jay Faulkner 25 Mar '24

25 Mar '24

Hi all, The next TC meeting is scheduled for tomorrow at 1800 UTC in #openstack-tc on OFTC. The proposed agenda is: - Roll call - Follow up on tracked action items - Gate health check - Implementation of Unmaintained branch statuses - 2024.2 Dalmatian TC Election - Election results cannot be merged due to affiliation diversity policy https://review.opendev.org/c/openstack/governance/+/913912 - TC vPTG 2024.2 - https://etherpad.opendev.org/p/apr2024-ptg-os-tc - Open Discussion and Reviews Thanks, Jay Faulkner OpenStack TC Chair

1 0

[nova] Instance migration/resize changes availability zone
by Marc Vorwerk 25 Mar '24

25 Mar '24

Dear OpenStack Community, I am reaching out for support with an issue that is specifically affecting a single instance during migration or resize operations in our OpenStack environment. I want to emphasize that this problem is isolated and does not reflect a broader issue within our cloud setup. The issue arises when attempting a resize of the instance's flavor, which only differs in RAM+CPU specification. Unexpectedly, the instance attempts to switch its availability zone from az1 to az2, which is not the intended behavior. The instance entered an error state during the resize or migration process, with a fault message indicating 'ImageNotFound', because after the availability zone change the volume cant be reached. We use seperate ceph clusters per az. To debug this issue we enabled debug logs for the nova scheduler and found that the scheduler does not filter out any node with any of our enabled filter plugins. As a quick test we disabled a couple of compute nodes and could also verify that the ComputeFilter of the nova-scheduler still just returns the full list of all nodes in the cluster. So it seems to us that for some reason the nova-scheduler just ignores all enabled filter plugins for mentioned instance. It's worth noting that other instances with the same flavor on the same compute node do not exhibit these issues, highlighting the unique nature of this problem. Furthermore we checked all relevant database tables to see if for some reason something strange is saved for this instance but it seems to us that the instance has exactly the same attributes as other instances on this node. We are seeking insights or suggestions from anyone who might have experienced similar issues or has knowledge of potential causes and solutions. What specific logs or configuration details would be helpful for us to provide to facilitate further diagnosis? We greatly appreciate any guidance or assistance the community can offer. Best regards, Marc Vorwerk + Maximilian Stinsky

5 6

[neutron] Bug Deputy Report March 18 - March 24
by Lajos Katona 25 Mar '24

25 Mar '24

Hi Neutron Team, I was the bug deputy for Neutron from 18March to 24 March, here comes my report for the week. - https://bugs.launchpad.net/neutron/+bug/2058400 ([ovn-octavia-provider] functional jobs are unstable) - Fernando Royo started to investigate the issues - https://bugs.launchpad.net/neutron/+bug/2058400/comments/2 - https://bugs.launchpad.net/neutron/+bug/2058378 ([devstack-tobiko-neutron] stable/2023.2 periodic broken with ERROR: Cannot install tox==4.13.0, tox==4.14.0 and tox==4.14.1) - https://review.opendev.org/c/x/devstack-plugin-tobiko/+/913746 fixed the failure. - https://bugs.launchpad.net/neutron/+bug/2058712 ([openvswitch-agent] Trunk extension should not be loaded if service plugin is disabled) - In progress: https://review.opendev.org/c/openstack/neutron/+/913979 - https://bugs.launchpad.net/neutron/+bug/2055419 (network autoallocation fails for non-admin user) - Incomplete: It seems something is missing for the reproduction - https://bugs.launchpad.net/neutron/+bug/2058433 (a public network with multi subnets , but based on ovn, They can't communicate with each other) - Incomplete: I try to collect some configurations, but somebody with more OVN background should check it also. Best wishes Lajos Katona (lajoskatona)

1 0

Please Help To Setup Bumblebee VDI project based on DevStack
by Matthew Swigart 24 Mar '24

24 Mar '24

Hello, I'm trying to install the VDI project on my Ubuntu 22.04 LTS Desktop VMware workstation. So I chose Bumblebee(https://github.com/NeCTAR-RC/bumblebee) and went through several steps like configuring the devstack, installing docker, and Bumblebee project. And then, I tried to create a virtual desktop from Bumblebee and I got the below error: ValueError: badly formed hexadecimal UUID string Attached error screenshot: [image: image.png] Anybody has already experienced a similar issue or does anybody have any idea to solve this problem? Then please help me. Looking forward to hearing from you. Much appreciated. Matthew

3 2

[all][elections][ptl] 2024.2 Dalmatian: PTL Election Conclusion & Results
by Ian Y. Choi 24 Mar '24

24 Mar '24

Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability. Thank you to all those who make this process possible. Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Adjutant - Dale Smith (dalees) * Barbican - Grzegorz Grasza (xek) * Blazar - Pierre Riteau (priteau) * Cinder - Jon Bernard () * Cloudkitty - Rafael Weingartner () * Cyborg - alex song (songwenping) * Designate - Michael Johnson (johnsom) * Glance - Pranali Deore (pdeore) * Heat - Takashi Kajinami (tkajinam) * Horizon - Tatiana Ovchinnikova (tmazur) * Ironic - Riccardo Pittau (rpittau) * Keystone - Dave Wilde (d34dh0r53) * Kolla - Michal Nasiadka (mnasiadka) * Magnum - Jake Yip (jakeyip) * Manila - Carlos Silva (carloss) * Masakari - sam sue () * Mistral - axel vanzaghi () * Monasca - Hasan Acar () * Neutron - Brian Haley (haleyb) * Nova - Sylvain Bauza (bauzas) * Octavia - Gregory Thiemonge (gthiemonge) * OpenStack Helm - Vladimir Kozhukalov (kozhukalov) * OpenStackAnsible - Dmitriy Rabotyagov (noonedeadpunk) * OpenStackSDK - Artem Goncharov (gtema) * Puppet OpenStack - Takashi Kajinami (tkajinam) * Quality Assurance - Martin Kopec (kopecmartin) * Rally - Andrey Kurilin (andreykurilin) * Storlets - Takashi Kajinami (tkajinam) * Sunbeam - Hemanth Nakkina () * Swift - Tim Burke (timburke) * Tacker - Yasufumi Ogawa (yasufum) * Telemetry - Erno Kuvaja (jokke_) * Venus - Eric Zhang () * Vitrage - Dmitriy Rabotyagov (noonedeadpunk) * Zaqar - Hao Wang (wanghao) * Zun - Hongbin Lu () Elections: no election required. For remaining projects (without PTL candidates), TC will work on the appointment. Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all involved in the PTL election process, Ian Y. Choi, on behalf of the OpenStack Technical Election Officials

1 0

Accessing virsh in openstack wallaby | tripleo
by Swogat Pradhan 24 Mar '24

24 Mar '24

Hi, Can someone please tell me how can i access the virsh utility on the compute node on openstack wallaby? Previously we used nova_libvirt but in wallaby there are multiple containers and i am unable to use virsh utility to edit my domain.xml file. List of containers: [root@dcn01-hci-2 ~]# podman ps | grep nova 10d981158842 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtlogd_wrapper e91667516afc 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtsecretd a4b07fe0e833 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtnodedevd d7e1db393e9c 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtstoraged 5308a171793e 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtqemud f490a6249ba1 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 6 weeks ago nova_virtproxyd ab0441e56957 172.25.201.68:8787/tripleomaster/openstack-nova-compute:current-tripleo kolla_start 2 months ago Up 2 months ago (healthy) nova_migration_target f35fbba5b690 172.25.201.68:8787/tripleomaster/openstack-nova-compute:current-tripleo kolla_start 2 months ago Up 6 weeks ago (unhealthy) nova_compute 82bc01993106 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo /usr/sbin/virtlog... 2 months ago Up 2 months ago Can someone please suggest how I can i edit an instance xml file in this setup? With regards, Swogat Pradhan

2 5

Openstack trove Error launching instance
by Shameem Farhath 22 Mar '24

22 Mar '24

Hi Team, Myself Shameem, on behalf of NerveDigital i am writing this mail. We are provisioning the trove database as a service in our existing infrastructure, and we got an ERROR on launching a DB instance. We have been troubleshooting it for a while and find no hope. Please help us to find a proper resolution for the issue. Please find the attached ERROR while launching the instance. Openstack version: yoga Operating system used: Ubuntu 22.04 Guest operating system: ubuntu jammy (downloaded from opendev tarball) Configuration files: Attached ERROR from the log: Attached *Regards,* *Shameem Farhath A* *9562440781* *www.NerveDigital.net* <http://www.NerveDigital.net>

1 0

[openstack-ansible][horizon][keystone] multidomain - LDAP admins unable to see Horizon Admin Dashboard
by Janet 'Saoirse' Sullivan 22 Mar '24

22 Mar '24

Hi, I have a multi-domain setup (LDAP and Default) and while LDAP users can see the Projects and Identity tabs in the Horizon dashboard, they can't see the Admin tab, even if they are assigned the admin role. The Default domain admin user can see this dashboard just fine. Is there a policy that needs to be changed so LDAP users with the admin role can see the Admin tab in Horizon? Openstack 2023.2.

1 0

[TC][all] Recheck analysis
by Sławek Kapłoński 22 Mar '24

22 Mar '24

Hi Stackers, Some time ago I started monitoring something what we have called "bare rechecks" which are "recheck" comments without any reason given. I was also asking various teams to improve that, try to check failures of the CI jobs and put some kind of reason in the recheck comment. That went pretty well and currently most of the teams are doing pretty good job there. See stats from last 30 days: +--------------------+---------------+--------------+-------------------+ | Team | Bare rechecks | All Rechecks | Bare rechecks [%] | +--------------------+---------------+--------------+-------------------+ | OpenStackSDK | 8 | 8 | 100.0 | | OpenStack-Helm | 41 | 41 | 100.0 | | cloudkitty | 1 | 1 | 100.0 | | monasca | 6 | 6 | 100.0 | | skyline | 2 | 2 | 100.0 | | trove | 1 | 1 | 100.0 | | rally | 1 | 1 | 100.0 | | watcher | 1 | 1 | 100.0 | | mistral | 5 | 8 | 62.5 | | kuryr | 1 | 2 | 50.0 | | zaqar | 1 | 2 | 50.0 | | horizon | 6 | 15 | 40.0 | | swift | 9 | 25 | 36.0 | | manila | 5 | 14 | 35.71 | | kolla | 14 | 68 | 20.59 | | cinder | 15 | 77 | 19.48 | | ironic | 10 | 53 | 18.87 | | glance | 11 | 59 | 18.64 | | requirements | 13 | 73 | 17.81 | | Telemetry | 2 | 12 | 16.67 | | nova | 16 | 105 | 15.24 | | OpenStackAnsible | 5 | 40 | 12.5 | | magnum | 1 | 9 | 11.11 | | neutron | 13 | 118 | 11.02 | | Quality Assurance | 3 | 30 | 10.0 | | Release Management | 1 | 12 | 8.33 | | octavia | 2 | 34 | 5.88 | | keystone | 0 | 1 | 0.0 | | OpenStack Charms | 0 | 1 | 0.0 | | oslo | 0 | 8 | 0.0 | | Puppet OpenStack | 0 | 95 | 0.0 | | barbican | 0 | 2 | 0.0 | | designate | 0 | 4 | 0.0 | | heat | 0 | 7 | 0.0 | | tacker | 0 | 63 | 0.0 | | tripleo | 0 | 4 | 0.0 | +--------------------+---------------+--------------+-------------------+ Now I though that it's time for the "next step" so I spent some time looking at the reasons of the rechecks done in last 30 days. I collected those reasons with script [1] and here are some top reasons found: +----------------------------------------------------------+----------------------+ | Recheck comment | Number of occurences | +----------------------------------------------------------+----------------------+ | recheck unrelated failure | 48 | | recheck irrelevant failure | 45 | | recheck unrelated test failure | 9 | | recheck testing | 9 | | recheck infra-failure | 9 | | recheck tempest-slow-py3 | 8 | | recheck nova-next | 8 | | recheck timeout | 7 | | recheck neutron-functional-with-uwsgi | 7 | | recheck failure not related to this change | 7 | | recheck ovn-octavia-provider-functional-master unrelated | 7 | | recheck jobs running too early | 6 | | recheck dependency updated | 5 | | recheck random failure | 5 | | recheck - bifrost bug | 5 | +----------------------------------------------------------+----------------------+ Those comments as they were put in the gerrit. Of course there was much more different comments there. I just wanted to highlight here some of the most common ones. I also asked ChatGPT to group all of them in some common groups. Below are some of the main categories of the reason found by the ChatGPT: CI/Testing Issues: Timeouts in various tests (e.g., tempest tests, tox tests). Infrastructure failures impacting CI. Kernel panics or guest panics during testing. Dependency-related failures (merged or updated). Unexpected failures or intermittent issues. Dependency Management: Dependency patches merged or updated. Dependency-related failures. Release/Documentation Updates: Release note fixes or updates. Content cleanup or removal. Documentation-related failures. Infrastructure/Tooling: Infrastructure mirror issues. Tooling updates or fixes (e.g., grub2-tools, proliantutils). Issues related to mirror servers. Specific Project/Component Issues: Nova-related failures (e.g., nova-ceph-multistore). Cinder-related failures (e.g., cinder-plugin-ceph-tempest). OpenStack SDK related failures. Configuration/Setup Problems: Problems with deployment or setup (e.g., grub2-tools missing, bifrost bug). Issues with configurations (e.g., host patterns). Network/Connection Problems: DNS resolution issues. Timeout errors related to network operations. Post-Failure Analysis: Attempts to reproduce failures. Investigation into infrastructural problems. Finally some conclusion from this analysis. It seems that our most common reason of the gate instability is something called "unrelated/irrelevant failure" and also things like "infra failure". In both cases we can't really do much to try to improve that as this information is not enough. So I would like to ask all of You to try to be more precise in the recheck comments and give more detailed reasons why You recheck Your patch. If for example You have to recheck the patch due to "unrelated failure", please write there also bug number which cause failure or simply give there name of the unrelated failed test or something like that. That way when I will do similar analysis in e.g. month from now maybe it will be easier to identify most common bugs which are causing "unrelated failures" and try to prioritize somehow work on fix of that bug. [1] https://github.com/slawqo/rechecks-stats/blob/main/rechecks_stats/rechecks_… -- Slawek Kaplonski Principal Software Engineer Red Hat

8 16