July 2024 - openstack-discuss - lists.openstack.org

openstack cli
by Gk Gk 08 Jul '24

08 Jul '24

Hi all, Is there a tool available in openstack, using which, as admin, we can list the operations executed by users like, vm operations , network related etc given their tenant uuid ? Do you think it is a good idea to have such a tool ? Thanks Y.G

2 1

when deleting an instance, its volume is not deleted
by kjme001＠gmail.com 08 Jul '24

08 Jul '24

I have the following problem, when deleting an instance, its volume is not deleted along with it, the volume remains and I then have to execute the command to detach the volume from the non-existent instance and then delete it. I don't know what could be causing this, the volume should probably be deleted together with the instance being deleted Thank you for your help

4 3

[neutron] Bug deputy July 01 - July 07
by Lajos Katona 08 Jul '24

08 Jul '24

Hi Neutrinos, This is the bug report from the first week of July: *High*: * https://bugs.launchpad.net/neutron/+bug/2071818 ("over 4096 resubmit actions" error occurs when there are ~250 neutron routers on a provider network) ** In progress: https://review.opendev.org/c/openstack/neutron/+/923391 * https://bugs.launchpad.net/neutron/+bug/2072154 (Port status goes BUILD when migrating non-sriov instance in sriov setting. ) ** In Progress: https://review.opendev.org/c/openstack/neutron/+/923467 * https://bugs.launchpad.net/neutron/+bug/2072466 (FWaaS does not apply rules to routers under DVR agents) ** In Progress: https://review.opendev.org/c/openstack/neutron-fwaas/+/922963 *Medium*: * https://bugs.launchpad.net/neutron/+bug/2071920 (The periodic workers service should run only ``PeriodicWorker`` instances) ** In Progress: https://review.opendev.org/c/openstack/neutron/+/923500 *Invalid*: * https://bugs.launchpad.net/neutron/+bug/2071721 ([OVN] unshelve not working when referenced by allowed address ) Best Wishes Lajos Katona (lajoskatona)

1 0

attach both virtio-scsi and virtio-blk to an instance
by Jiatong Shen 07 Jul '24

07 Jul '24

Hello, I am searching whether it is possible to use both virtio-scsi and virtio-blk at the same time for one instance. I knew it was possible to use each of them separately. I have this requirement because virtio-blk is not possible to support as many as devices like virtio-scsi, but we still want to keep virtio-blk for performance reasons and for legacy instances. Thank you for help. -- Best Regards, Jiatong Shen

2 2

Kolla-Ansible Issues
by Alexandra Rong 05 Jul '24

05 Jul '24

Hello OpenStack-Ansible team, We are students in Germany studying Business Informatics. Currently, we have a project where we need to build an OpenStack environment using Kolla-Ansible. Our goal is to use Gnocchi and CloudKitty to gather metrics on the usage of the VMs in OpenStack. We tried following the official Kolla-Ansible deployment guide but encountered issues starting Kolla-Ansible, as shown in the attached screenshots. Could you possibly help us? Best regards, Felix and Alexandra Ansible.cfg: Error: All-in-one:

5 4

[openstack-helm] SQLAlchemy 2.0 support
by Mohammed Naser 05 Jul '24

05 Jul '24

Hi everyone! It seems like our db-init jobs are broken with the latest version of OpenStack because it doesn’t work with SQLAlchemy 2.0 2024-05-31 03:21:34,290 - OpenStack-Helm DB Init - INFO - Got DB root connection 2024-05-31 03:21:34,290 - OpenStack-Helm DB Init - INFO - Using /etc/keystone/keystone.conf as db config source 2024-05-31 03:21:34,292 - OpenStack-Helm DB Init - INFO - Trying to load db config from database:connection 2024-05-31 03:21:34,292 - OpenStack-Helm DB Init - INFO - Got config from /etc/keystone/keystone.conf 2024-05-31 03:21:34,331 - OpenStack-Helm DB Init - INFO - Tested connection to DB @ percona-xtradb-haproxy.openstack.svc.cluster.local:3306 as root 2024-05-31 03:21:34,332 - OpenStack-Helm DB Init - INFO - Got user db config 2024-05-31 03:21:34,332 - OpenStack-Helm DB Init - CRITICAL - Could not create database keystone Traceback (most recent call last): File "/tmp/db-init.py", line 112, in <module> root_engine.execute("CREATE DATABASE IF NOT EXISTS {0}".format(database)) AttributeError: 'Engine' object has no attribute 'execute' I was wondering if it makes sense to fix this, or if this is something that we should just take the time to simply replace with some sort of simple operator that creates manages/watches database CRs (if one doesn’t exist?) Thanks Mohammed

2 2

[kuryr][tc] Final call for Kuryr PTL/DPL liaisons
by Ghanshyam Mann 05 Jul '24

05 Jul '24

Hello Everyone, Kuryr project ends up being a leaderless project for the 2024.2 Dalmatian cycle[1]. There is no volunteer to serve as PTL or DPL liaisons yet. As the next step, I have proposed to mark this project Inactive: - https://review.opendev.org/c/openstack/governance/+/916945 If you would like to serve as a leader and help maintain this project, this is the right time to step up by replying to this email or commenting in gerrit change 916945. [1] https://etherpad.opendev.org/p/2024.2-leaderless#L99 Ref: https://governance.openstack.org/tc/reference/emerging-technology-and-inact… -gmann

4 9

[ironic] the fate of ironic-hardware-inventory-recorder-image
by Dmitry Tantsur 05 Jul '24

05 Jul '24

Hi folks! The project in question (https://github.com/metal3-io/ironic-hardware-inventory-recorder-image) was created as part of our effort to allow updating introspection data in ironic-inspector from inside of already running ("active" in the ironic terminology) instances. It is a container image that packages ironic-python-agent in a way that limits its activity to finding ironic-inspector and posting data to it. The initial plans did not happen, ironic-inspector is pending deprecation in favor of ironic's built-in inspection, and the project is unused by anyone in the Metal3 ecosystem. We want to archive and eventually remove it, but we've heard that some members of the ironic community (CERN? CC'ing Arne) are using it. If you do have an interest in this approach, please reach out to me to organize a take-over of the project. Dmitry

4 5

[release] Release countdown for week R-12, Jul 08-12
by Elõd Illés 05 Jul '24

05 Jul '24

Development Focus ----------------- We are now past the Dalmatian-2 milestone, and entering the last development phase of the cycle. Teams should be focused on implementing planned work for the cycle. Now is a good time to review those plans and reprioritize anything if needed based on the what progress has been made and what looks realistic to complete in the next few weeks. General Information ------------------- Looking ahead to the end of the release cycle, please be aware of the feature freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (August 22nd, 2024). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (August 29th, 2024) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, August 29th, 2024. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (September 12th, 2024) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (September 25th, 2024) Upcoming Deadlines & Dates -------------------------- Non-client library freeze: August 22nd, 2024 (R-6 week) Client library freeze: August 29th, 2024 (R-5 week) Dalmatian-3 milestone: August 29th, 2024 (R-5 week) Előd Illés irc: elodilles @ #openstack-release

1 0

[neutron] Neutron drivers meeting cancelled
by Rodolfo Alonso Hernandez 05 Jul '24

05 Jul '24

Hello Neutrinos: Due to the lack of quorum, today's Neutron drivers meeting will be cancelled. Have a nice weekend.

1 0

[horizon][python-openstackclient] Hypervisor listed in dashboard but not in CLI
by Francesco Di Nucci 05 Jul '24

05 Jul '24

Hello, I am having a strange "error" with an hypervisor. It works and it is shown in Horizon under /Admin/System/System Information/Compute Services/, but it is not listed through the CLI with /openstack hypervisor list/ Any suggestion on how to prevent this? Thanks in advance -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email:francesco.dinucci@na.infn.it

1 0

Magnum Caracal: how to use the K8s cluster API instead of Heat driver
by Michel Jouvin 05 Jul '24

05 Jul '24

Hi, In our testing of Caracal Magnum, we saw that the cluster upgrade feature is now disabled for clusters using the Heat driver. There are many good reasons for this explained at [1] and [2] in particular. But I don't see any Magnum documentation of this new approach to K8s cluster provisionning. Is https://vexxhost.github.io/magnum-cluster-api/ the authoritative place? I had a quick look to the URL above but I am not sure I understood what configures Magnum to use Cluster API rather than Heat driver. Is Magnum configured to use one or the other for all clusters it manages? Is it a per cluster choice? How it works to transition from Heat driver to Cluster API, ie how it works if you have existing clusters configured with Heat drivers and if you are creating new ones with Cluster API? Best regards, Michel [1] https://opendev.org/openstack/magnum/commit/2fd3059f3885ff4a14f7f0141016196… (see comments in the code, at line 313) [2] https://vexxhost.com/blog/cluster-api-driver-openstack-magnum/

1 0

[manila] Bugsquash event: Jul 10th to 12th
by Carlos Silva 04 Jul '24

04 Jul '24

Hello, zorilla and interested stackers! We are going to have our first bugsquash of this cycle in the next week. For this event, we will be focusing on pursuing closure for bugs that are currently in progress. - It will start next Wednesday (July 10) and ends on Friday (July 12th). - We will have a kick-off meeting to go over the list of bugs as usual on Wednesday, 14 UTC, and work on assignments if needed. - We will use half of the next upstream weekly meeting to talk about the progress and discuss ongoing reviews. All of the details will be added to the bugsquash etherpad [1]. Looking forward to closing a lot of bugs with your help! [1] https://etherpad.opendev.org/p/manila-dalmatian-m2-bugsquash Regards, carloss

1 0

[CloudKitty] query regarding ElasticSearch usage
by Rafael Weingärtner 04 Jul '24

04 Jul '24

Hello OpenStack community and users of CloudKitty! There have been some discussions in our bi-weekly meetings and vPTG meetings regarding the deprecation and removal of ElasticSearch support as a storage backend. Therefore, this e-mail is to consult/query users regarding ElasticSearch users. If there are no people using it anymore with CloudKitty, we are considering the alternative of removing it and maintaining only the OpenSearch support. We would like to hear back from you guys. Let me know if you are using ElasticSearch, and if you intend to stick with it. Also, do you guys feel the need to improve something in its support in CloudKitty. Thanks in advance for your feedback! -- Rafael Weingärtner

5 5

Magnum issues http requests to other services when internal/admin endpoint is https
by Michel Jouvin 04 Jul '24

04 Jul '24

Hi, We have reconfigured our cloud with a Nginx sever handling TLS in front of every API service, as described in https://docs.openstack.org/security-guide/secure-communication/secure-refer…. Previously we used to have Magnum/Heat/Barbican endpoints using http rather than https (not good!). Since this change, we have seen problems in Magnum (starting in Antelope when we did the change but still present in Caracal) where some "internal" requests to Barbican and Heat are done in http rather than https. We worked around this defining a redirect to https on 497 status code, as documented in Nginx documentation but it is not really satisfying as it means all clients, not only Magnum service, could use http on the https port and get serviced. I remember seing an issue on Launchpad about this issue but forgot the issue number. We were wondering wether it would not be better, at least until the problem is fixed, to define the internal+admin endpoints with http rather than https. According to our tests, it fixes the problem, as expected. Thanks in advance for any thought or experience on this. Best regards, Michel

2 2

[nova] volume information was duplicated when Live Migration failed
by Junya Noguchi (Fujitsu) 04 Jul '24

04 Jul '24

To whom it may concern Hi. I encountered an issue with OpenStack where volume information was duplicated when Live Migration failed. Could you please provide a solution to this issue? [Issue] After a Live Migration failure, when I checked the volume where the error occurred using the 'openstack volume list' command, the following was displayed: +--------------------------------------+-----------------------------------+-----------+------+---------------------------------------------------------------------------------------------------------------------------------------------+ | ID | Name | Status | Size | Attached to | +--------------------------------------+-----------------------------------+-----------+------+---------------------------------------------------------------------------------------------------------------------------------------------+ | 9ba9734f-575e-41de-8bb4-60839388e0ad | | in-use | 10 | Attached to 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda Attached to 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda Attached to | | | | | | 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda Attached to 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda Attached to | | | | | | 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda Attached to 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda Attached to | | | | | | 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda Attached to 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda | I expect that the 'Attached to' display should only appear once as there is one volume connected, but it is duplicated for each failed attempt. The versions of OpenStack and nova are as follows: OpenStack Zed $ openstack --version openstack 6.0.0 $ nova --version nova CLI is deprecated and will be a removed in a future release 18.1.0 [Details] The volume display is duplicated under the following conditions: - When Live Migration of an instance fails If the communication between the ports required for Live Migration is closed, Live Migration will fail when executed. $ sudo netstat -tuln | grep 16509 $ The output of nova-compute.log at the time of Live Migration failure is as follows: --- 2024-02-28 17:04:32.119 2785 ERROR nova.virt.libvirt.driver [-] [instance: 521eb55f-535d-4fa7-a27e-447b0bbae9b4] Live Migration failure: unable to connect to server at 'XXXXX.com:16509': Connection refused: libvirt.libvirtError: unable to connect to server at 'XXXXX.com:16509': Connection refused 2024-02-28 17:04:32.119 2785 DEBUG nova.virt.libvirt.driver [-] [instance: 521eb55f-535d-4fa7-a27e-447b0bbae9b4] Migration operation thread notification thread_finished /usr/lib/python3.9/site-packages/nova/virt/libvirt/driver.py:10516 2024-02-28 17:04:32.607 2785 DEBUG nova.virt.libvirt.migration [-] [instance: 521eb55f-535d-4fa7-a27e-447b0bbae9b4] VM running on src, migration failed _log /usr/lib/python3.9/site-packages/nova/virt/libvirt/migration.py:432 2024-02-28 17:04:32.608 2785 DEBUG nova.virt.libvirt.driver [-] [instance: 521eb55f-535d-4fa7-a27e-447b0bbae9b4] Fixed incorrect job type to be 4 _live_migration_monitor /usr/lib/python3.9/site-packages/nova/virt/libvirt/driver.py:10330 2024-02-28 17:04:32.608 2785 ERROR nova.virt.libvirt.driver [-] [instance: 521eb55f-535d-4fa7-a27e-447b0bbae9b4] Migration operation has aborted --- After Live Migration, when I check the volume where the error occurred using the 'openstack volume list' command, the following is displayed: +--------------------------------------+-----------------------------------+-----------+------+---------------------------------------------------------------------------------------------------------------------------------------------+ | ID | Name | Status | Size | Attached to | +--------------------------------------+-----------------------------------+-----------+------+---------------------------------------------------------------------------------------------------------------------------------------------+ | 9ba9734f-575e-41de-8bb4-60839388e0ad | | in-use | 10 | Attached to 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda Attached to 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda Attached to | | | | | | 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda Attached to 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda Attached to | | | | | | 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda Attached to 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda Attached to | | | | | | 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda Attached to 73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda | '73c4c6e8-fe34-4f87-9f26-e70b4cc593ba on /dev/vda' is displayed as many times as Live Migration failed. The duplicate display did not disappear even after Live Migration was successful. Thanks,

2 2

[kolla-ansible][letsencrypt] containers are running but not getting certificates.
by Jonathan Proulx 03 Jul '24

03 Jul '24

Hi All, I'm trying to do a test multinode deploy using 2023.2 I have letsencrypt_webserver and letsencrypt_lego contsainers running and I'm seeing random traffic in the /var/log/kolla/letsencrypt/letsencrypt-webserver-access.log so fairly confident they're plumbed through to the public internet properly, but I don't seem to be getting certificates. how can I trigger a renewal attempt so I can maybe see what I've screwed up? Thanks, -Jon -- Jonathan Proulx (he/him) Sr. Technical Architect The Infrastructure Group MIT CSAIL

3 6

[tc][all][monasca ] Retiring the Monasca project
by Ghanshyam Mann 03 Jul '24

03 Jul '24

Hello everyone, As you might know, the Monasca project is not active and was marked 'inactive' since 2024.1 cycle[1]. In this cycle also, this project is leaderless[2] and no maintainer stepped up to maintain it. As discussed in the Leaderless project etherpad[2], the next step is to retire the project. I'm sending this email to propose the Monasca retirement and based on the response, I will proceed next. [1] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [2] https://etherpad.opendev.org/p/2024.2-leaderless#L72 -gmann

6 14

[OSSA-2024-001] OpenStack Cinder, Glance, Nova: Arbitrary file access through custom QCOW2 external data (CVE-2024-32498)
by Jeremy Stanley 02 Jul '24

02 Jul '24

======================================================================= OSSA-2024-001: Arbitrary file access through custom QCOW2 external data ======================================================================= :Date: July 02, 2024 :CVE: CVE-2024-32498 Affects ~~~~~~~ - Cinder: <22.1.3, >=23.0.0 <23.1.1, ==24.0.0 - Glance: <26.0.1, ==27.0.0, >=28.0.0 <28.0.2 - Nova: <27.3.1, >=28.0.0 <28.1.1, >=29.0.0 <29.0.3 Description ~~~~~~~~~~~ Martin Kaesberger reported a vulnerability in QCOW2 image processing for Cinder, Glance and Nova. By supplying a specially created QCOW2 image which references a specific data file path, an authenticated user may convince systems to return a copy of that file's contents from the server resulting in unauthorized access to potentially sensitive data. All Cinder deployments are affected; only Glance deployments with image conversion enabled are affected; all Nova deployments are affected. Patches ~~~~~~~ - https://review.opendev.org/923247 (2023.1/antelope(cinder)) - https://review.opendev.org/923277 (2023.1/antelope(glance)) - https://review.opendev.org/923278 (2023.1/antelope(glance)) - https://review.opendev.org/923279 (2023.1/antelope(glance)) - https://review.opendev.org/923280 (2023.1/antelope(glance)) - https://review.opendev.org/923281 (2023.1/antelope(glance)) - https://review.opendev.org/923282 (2023.1/antelope(glance)) - https://review.opendev.org/923283 (2023.1/antelope(glance)) - https://review.opendev.org/923288 (2023.1/antelope(nova)) - https://review.opendev.org/923289 (2023.1/antelope(nova)) - https://review.opendev.org/923290 (2023.1/antelope(nova)) - https://review.opendev.org/923281 (2023.1/antelope(nova)) - https://review.opendev.org/923246 (2023.2/bobcat(cinder)) - https://review.opendev.org/923266 (2023.2/bobcat(glance)) - https://review.opendev.org/923267 (2023.2/bobcat(glance)) - https://review.opendev.org/923268 (2023.2/bobcat(glance)) - https://review.opendev.org/923269 (2023.2/bobcat(glance)) - https://review.opendev.org/923270 (2023.2/bobcat(glance)) - https://review.opendev.org/923271 (2023.2/bobcat(glance)) - https://review.opendev.org/923272 (2023.2/bobcat(glance)) - https://review.opendev.org/923284 (2023.2/bobcat(nova)) - https://review.opendev.org/923285 (2023.2/bobcat(nova)) - https://review.opendev.org/923286 (2023.2/bobcat(nova)) - https://review.opendev.org/923287 (2023.2/bobcat(nova)) - https://review.opendev.org/923245 (2024.1/caracal(cinder)) - https://review.opendev.org/923259 (2024.1/caracal(glance)) - https://review.opendev.org/923260 (2024.1/caracal(glance)) - https://review.opendev.org/923261 (2024.1/caracal(glance)) - https://review.opendev.org/923262 (2024.1/caracal(glance)) - https://review.opendev.org/923263 (2024.1/caracal(glance)) - https://review.opendev.org/923264 (2024.1/caracal(glance)) - https://review.opendev.org/923265 (2024.1/caracal(glance)) - https://review.opendev.org/923273 (2024.1/caracal(nova)) - https://review.opendev.org/923274 (2024.1/caracal(nova)) - https://review.opendev.org/923275 (2024.1/caracal(nova)) - https://review.opendev.org/923276 (2024.1/caracal(nova)) - https://review.opendev.org/923244 (2024.2/dalmatian(cinder)) - https://review.opendev.org/923248 (2024.2/dalmatian(glance)) - https://review.opendev.org/923249 (2024.2/dalmatian(glance)) - https://review.opendev.org/923250 (2024.2/dalmatian(glance)) - https://review.opendev.org/923251 (2024.2/dalmatian(glance)) - https://review.opendev.org/923252 (2024.2/dalmatian(glance)) - https://review.opendev.org/923253 (2024.2/dalmatian(glance)) - https://review.opendev.org/923254 (2024.2/dalmatian(glance)) - https://review.opendev.org/923255 (2024.2/dalmatian(nova)) - https://review.opendev.org/923256 (2024.2/dalmatian(nova)) - https://review.opendev.org/923257 (2024.2/dalmatian(nova)) - https://review.opendev.org/923258 (2024.2/dalmatian(nova)) Credits ~~~~~~~ - Martin Kaesberger (CVE-2024-32498) References ~~~~~~~~~~ - https://launchpad.net/bugs/2059809 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-32498 Notes ~~~~~ - Due to the scope of the problem and complexity of the resulting fixes, regressions and additional bypasses were reported in the original bug by downstream stakeholders during the coordinated disclosure period. As a result, our initially chosen publication date was rescheduled, which put the advisory four days past our promised ninety day maximum embargo length. Additional revised patches and regression fixes were supplied to stakeholders as soon as possible, but we understand the unfortunate timing of these last-minute changes resulted in a lot of additional work for everyone involved. -- Jeremy Stanley OpenStack Vulnerability Management Team

2 1

[Cinder] Extending Specs Freeze Deadline to Jun 7
by Jon Bernard 02 Jul '24

02 Jul '24

Hello, As discussed in the last cinder meeting [1] we are extending the cinder specs freeze deadline to June 7. The previous week contains holidays for some on our team, so the weekend days are added to make sure everything that needs to merge has sufficient time to do so. Please make sure your specs are updated before the new deadline. [1]: https://meetings.opendev.org/meetings/cinder/2024/cinder.2024-06-26-14.00.l… Thanks, -- Jon

1 0

any idiomatic testtools / stestr patterns for asyncio?
by Mike Bayer 02 Jul '24

02 Jul '24

hey gang - I'm adding asyncio support to oslo.db. Fairly major block hit, which I can work around, is that testtools / stestr do not seem to have any provision for asyncio present. An initial attempt working with it gracefully looked like this (using oslotests base, which is the testtoolsTestBase): import unittest from oslotest import base class MyTestSuite(unittest.IsolatedAsyncioTestCase, base.BaseTestCase): # ... but that didn't work because the degree to which testtools modifies the run() method of unittest.TestCase prevents IsolatedAsyncioTestCase from running awaitable test cases. Next attempt is this, remove testtools / oslotest from the class hierarchy (which is bad, because we lose all of our testtools patterns): class MyTestSuite(unittest.IsolatedAsyncioTestCase): # ... this runs, however stestr sends into the test suite a Result object that is not a subclass of unittest.result.TestResult, it's a "subunit.test_results.AutoTimingTestResultDecorator" that does not TestResult in its MRO; unittest shows a warning that there is no addDuration() method on the result object. final workaround, patch one on, here's my base: class BaseAsyncioCase(unittest.IsolatedAsyncioTestCase): def run(self, result=None): # work around stestr sending a result object that's not a # unittest.TestResult result.addDuration = lambda test, elapsed: None return super().run(result=result) now I can run asyncio tests. But only by ditching testtools entirely. What would be the correct approach to introducing asyncio support in our test suites given our dependency on testtools?

4 6

Regarding Cinder Volume as a backend not mounting on Compute Node
by Adivya Singh 01 Jul '24

01 Jul '24

Hi Team, I am facing a issue, where my Cinder Volume is not getting mounted on Compute node, it creates Successfully, Here is my export file input on storage server /cinder/volume 172.29.244.0/22(rw,no_subtree_check,no_root_squash) and here is my NFS mount Option on Cinder as a backend nfs_mount_options: noatime,rw,bg,intr,async,timeo=60 it mounts successfully on Controller, but compute it get struck Regards Adivya Singh

1 0

[tacker] Cancel weekly meeting
by Yasufumi Ogawa 01 Jul '24

01 Jul '24

Hi team, I'm canceling today's meeting since I'm not available no new topic on the etherpad. Please feel free to host someone else if you have any topic. Thanks, Yasufumi

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2024.2/R-13)
by Goutham Pacha Ravi 01 Jul '24

01 Jul '24

Hello Stackers, We're officially at Milestone 2 of the 2024.2 ("Dalmatian") release cycle [1]. Alongside spec reviews and other project-specific deadlines, this is the week to look out for intermediary releases of several OpenStack projects and close out bug fixes, or re-target open ones for a future milestone. We're soon going to see some patches to add the code name that was picked for the 2025.1 release (31st release!) of OpenStack: "Epoxy" [2]. I probably jinxed the animal theme, but Kendall Nelson (diablo_rojo) told me that Epoxy will be "the glue that holds our clouds together." The Technical Committee was reviewing project activity in Monasca [3], Freezer, and Skyline [4]. As you've probably gathered from the discussion on this list and elsewhere, Monasca seems ready to leave the "inactive" project list and Skyline seems set to graduate from the "emerging" project list [5]. The respective project teams will need to make these proposals, and I'll keep you posted on how that evolves. The Freezer project team would like to continue to keep the "inactive" project tag through this release as they continue to stabilize the codebase and the CI jobs. This means that there will be no releases from the Freezer team during the 2024.2 ("Dalmatian") release cycle. Hervé Beraud (hberaud) and Mike Bayer (zzzeek) will be joining us at the Technical Committee monthly video meeting tomorrow (2024-07-02) to preview the work ahead of us to remove eventlet from OpenStack [6][7]. If you are an OpenStack project maintainer, packager, or operator, please consider joining so we can have a productive discussion. === Weekly Meeting === The Technical Committee met last week on OFTC's #openstack-tc IRC channel [8]. We discussed several in-progress changes, including a proposal to address affiliation diversity violations that may occur during TC elections. There was an emphasis on gate health. Thanks to a few patches to devstack, tempest, and devstack plugins, several integrated gate jobs were more stable over the past couple of weeks. As noted last week, CentOS Stream 8 is now EOL, and hence any test jobs that were relying on this OS are now perma-failing. This is a call-out to project maintainers to clean up their test jobs across all code branches. Currently, a search of trunk branches reveals that centos-stream-8 nodes are required for test jobs in Tempest, Rally, Tenks, Ansible tests, and tempest plugins of Octavia, Telemetry, and Cinder. Please do look at cruft left behind in older stable and "unmaintained" branches as well. TC members also brainstormed on projects that are seemingly active, but the project's core team is unresponsive to new contributors. This is against the Open Community principles that we adhere to [9]. If you're aware of instances of this happening, please do let the TC know. Our next weekly meeting is held simultaneously on Video and IRC. Details, including the meeting's agenda, are in [7]. I hope you'll be able to participate. As always, our IRC meetings are logged to eavesdrop [10], and our Video meeting recordings are uploaded to YouTube [11]. === Governance Proposals === ==== Merged ==== Show TC and SIG repos under reference | https://review.opendev.org/c/openstack/governance/+/918488 ==== Open for review/discussion ==== Retire kuryr-kubernetes and kuryr-tempest-plugin | https://review.opendev.org/c/openstack/governance/+/922507 Update to include docs and miscellaneous repos for AC status | https://review.opendev.org/c/openstack/governance/+/915021 Adding a rule to manage the affiliation diversity requirement in the TC | https://review.opendev.org/c/openstack/governance/+/922512 Update criteria for the inactive projects to become active again | https://review.opendev.org/c/openstack/governance/+/921500 Remove Eventlet From OpenStack | https://review.opendev.org/c/openstack/governance/+/902585 === Upcoming Events === 2024-07-02: Monthly Technical Committee Video+IRC meeting 2024-07-02: OpenInfra Board Meeting -: https://board.openinfra.dev/meetings/ 2024-07-04: Milestone-2 of the 2024.2 release cycle Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] Release Schedule: https://releases.openstack.org/dalmatian/schedule.html [2] OpenStack "Epoxy": https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] Reviving Monasca: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] Graduating Skyline: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] Emerging Technology and Inactive Projects: https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [6] Goal proposal to "Remove Eventlet from OpenStack": https://review.opendev.org/c/openstack/governance/+/902585 [7] Agenda for the OpenStack TC Meeting on 1st July 2024: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [8] TC Meeting log (2024-06-25): https://meetings.opendev.org/meetings/tc/2024/tc.2024-06-25-18.00.log.html [9] "Open Community": https://opendev.org/openinfra/four-opens/src/branch/master/doc/source/openc… [10] Past TC meetings: https://meetings.opendev.org/meetings/tc/ [11] YouTube channel recordings of past TC meetings: https://www.youtube.com/watch?v=34w1Aoai1EA&list=PLhwOhbQKWT7Ui1KPL7MLIq4ye…

1 0

problem with deleting a volume from OpenStack
by kjme001＠gmail.com 01 Jul '24

01 Jul '24

I have a problem with deleting a volume from OpenStack from a machine that no longer exists because it has crashed. If it executes the command: openstack volume delete volume_name receives the deleting status and the volume is not deleted, it is still in the deleting state. How can I delete such a volume? Can I remove it from the postgres database? Regards

2 4