- openstack-discuss - lists.openstack.org

[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

[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

[horizon][kolla-ansible][antelope]
by Andrej Moravčík 01 Jul '24

01 Jul '24

Hello, I have just observed Horizon behavior with Project Names displayed incorrectly in Admin / Overview page and I would like to ask if anybody else can confirm the same issue. It is apparently related to Horizon Multidomain support, which is not enabled by default and maybe it is not very used / tested feature. The issue is reported here: https://bugs.launchpad.net/horizon/+bug/2071630 Thanks. — Andrej Moravčík ________________________________ Táto správa a jej prílohy sú dôverné. Prosím, narábajte s týmito informáciami ako s dôvernými a nezverejňujte, nekopírujte ani neposielajte tieto informácie bez predchádzajúceho súhlasu spoločnosti Aliter Technologies, a.s. Ak nie ste adresátom indikovaným v záhlaví tejto správy alebo želaný príjemca, upovedomte prosím spoločnosť Aliter Technologies, a.s. odpoveďou na tento e-mail a pôvodnú správu vymažte zo svojho systému. Aliter Technologies - registrovaná ochranná známka pre EU, USA This message and any attachments are confidential. Please treat the information as confidential, and do not disclose, copy or deliver this message to anyone without Aliter Technologies' approval. If you are not the addressee indicated in this message or an intended recipient please notify Aliter Technologies a.s. by return e-mail and delete the message from your system. Aliter Technologies - Registered in WIPO & U.S. Patent and Trademark Office

1 0

[neutron] DHCP agent event processing multithread LP#2070376
by Rodolfo Alonso Hernandez 01 Jul '24

01 Jul '24

Hello Neutrinos: As discussed during the last Neutron drivers meeting, I said that I was going to benchmark the performance of the DHCP agent with and without multiple event processing threads. The result is in [2]. As expected, the number of threads attending the received events (network creation, port deletion, etc) does not affect the speed of the DHCP agent. In particular I tested the resync transient that happens during the DHCP agent restart, that is easy to reproduce and provides consistent results. Regards. [1]https://bugs.launchpad.net/neutron/+bug/2070376 [2]https://bugs.launchpad.net/neutron/+bug/2070376/comments/1

1 0

[neutron] Bug deputy Jun 24 - Jun 30
by Rodolfo Alonso Hernandez 01 Jul '24

01 Jul '24

Hello Neutrinos: This is the bug report from the last week: High: * https://bugs.launchpad.net/neutron/+bug/2071426: [DHCP] DHCP agent failing in ``DHCPResourceUpdate.__lt__`` method. Assigned to Rodolfo. Patch: https://review.opendev.org/c/openstack/neutron/+/923026 * https://bugs.launchpad.net/neutron/+bug/2071374: https://bugs.launchpad.net/neutron/+bug/2071374. Assigned to Roberto. Patch: https://review.opendev.org/c/openstack/neutron/+/922972 Medium: * https://bugs.launchpad.net/neutron/+bug/2071451: [ml2][ovs][firewall] port changes ofport and local_vlan will lead to wrong flow installation. Assigned to Liu. Patch: https://review.opendev.org/c/openstack/neutron/+/923040 Low: * https://bugs.launchpad.net/neutron/+bug/2070376: [eventlet-deprecation] Reduce the DHCP agent pool processing to a single thread. Assigned to Rodolfo. In progress. Whislist/RFE: * https://bugs.launchpad.net/neutron/+bug/2071323: [RFE] Flow logs support for OpenStack Networking. Not assigned but most probably Liu, the reporter, will take care of it once triaged and approved by the drivers team. Have a nice week.

1 0

Warehouse failure
by ゞPositive î 01 Jul '24

01 Jul '24

The Centos system has stopped updating now, and we hope that the official website manual Centos can be changed to Rocky Linux. Now we are using Rocky Linux to install OpenStack using the Centos system installation method. Among them, the installation source link for yum install Centos release openstack ussuri and yum install Centos release openstack xena is invalid. We hope to receive your solution. ゞPositive ? 451526204(a)qq.com  

2 1

2025.1 E OpenStack Release Naming Poll
by Allison Price 29 Jun '24

29 Jun '24

Hi everyone, It’s that time again! Please join me in voting to name the 31st release of OpenStack, starting with the letter ‘E’! https://civs1.civs.us/cgi-bin/vote.pl?id=E_d8469898c60545f2&akey=a16aa8cad5… The deadline to vote is Friday, June 28 at 7 UTC. Cheers, Allison

2 1

Openstack-ansible upgrade
by Danish Khan 28 Jun '24

28 Jun '24

Dear Team, We have few openstack-ansible Train release in our environment. We want to upgrade these setup to atleast Yoga release. Currently we are doing upgrade step by step. like from Train to Ussuri then to Victoria then to wallaby and so on(in N+1 series). Can we skip few releases and directly go to Yoga or any other feasible release? Regards, Danish Khan

4 3

[release] Release countdown for week R-13, Jul 01-05
by Elõd Illés 28 Jun '24

28 Jun '24

Development Focus ----------------- The Dalmatian-2 milestone is next week, on July 4th, 2024! 2024.2 Dalmatian-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/dalmatian/schedule.html for details. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library that has not been otherwise released since milestone 1. PTL's and release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well. A +1 would be appreciated, but if we do not hear anything at all by the end of the week, we will assume things are OK to proceed. Remember that non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. Next week is also the deadline to freeze the contents of the final release. All new '2024.2 Dalmatian' deliverables need to have a deliverable file in https://opendev.org/openstack/releases/src/branch/master/deliverables and need to have done a release by milestone-2. Upcoming Deadlines & Dates -------------------------- Dalmatian-2 Milestone: July 4th, 2024 Előd Illés irc: elodilles @ #openstack-release

1 0

Re: [manila] stuck at connecting ceph backend with manila
by Goutham Pacha Ravi 28 Jun '24

28 Jun '24

Hey Shubham, Please keep the conversation on the list. On Thu, Jun 27, 2024 at 10:36 PM Shubham Kumar Yadav <shubham.kumar.yadav369(a)gmail.com> wrote: > > Hi, actually the keyring file contains the manila keyring which is mounted on manila-share pod > > 1 -> ls -l /etc/ceph (from manila-share pod) > total 12 > -rw-r--r-- 1 root root 279 Jun 26 08:02 ceph.conf > -rw-r--r-- 1 root root 62 Jun 26 08:02 keyring > -rw-r--r-- 1 root root 92 Mar 4 20:27 rbdmap > > 2 -> i have already generated manila keyring Do you mean the content of the keyring is in the "keyring" file? In your earlier email you showed the contents of your ceph.conf, it referred to the file name of the manila keyring as "/etc/ceph/manila.keyring". I don't see that file in the output above. > > On Fri, 28 Jun 2024 at 00:46, Goutham Pacha Ravi <gouthampravi(a)gmail.com> wrote: >> >> Hi, >> >> On Thu, Jun 27, 2024 at 12:26 AM Shubham Kumar Yadav >> <shubham.kumar.yadav369(a)gmail.com> wrote: >> > >> > Hi, these are the outputs you asked for >> > >> > 1 -> ls -l /etc/ceph >> > total 12 >> > -rw-r--r-- 1 root root 279 Jun 26 08:02 ceph.conf >> > -rw-r--r-- 1 root root 62 Jun 26 08:02 keyring >> > -rw-r--r-- 1 root root 92 Mar 4 20:27 rbdmap >> >> The manila keyring is missing here; Can you add it here and retry? >> >> >> > >> > >> > 2 -> ceph --verbose fs ls -n client.manila >> > parsed_args: Namespace(admin_socket=None, block=False, cephconf=None, client_id=None, client_name='client.manila', cluster=None, cluster_timeout=None, completion=False, help=False, input_file=None, output_file=None, output_format=None, period=1, setgroup=None, setuser=None, status=False, verbose=True, version=False, watch=False, watch_channel=None, watch_debug=False, watch_error=False, watch_info=False, watch_sec=False, watch_warn=False), childargs: ['fs', 'ls'] >> > [errno 1] RADOS permission error (error connecting to the cluster) >> > >> > 3 -> i created keyring using >> > >> > ceph auth get-or-create client.manila -o manila.keyring \ >> > mgr 'allow rw' \ >> > mon 'allow r' >> > >> > >> > Hope to hear from you soon >> > Thank you! >> > >> > >> > >> > On Thu, 27 Jun 2024 at 05:25, Goutham Pacha Ravi <gouthampravi(a)gmail.com> wrote: >> >> >> >> The client capabilities look correct; Can you paste the output of "ls >> >> -l /etc/ceph" from the manila-share pod? >> >> Also attempt to use "--verbose" with the Ceph CLI; maybe there'll be a >> >> helpful log: "ceph --verbose fs ls -n client.manila" >> >> >> >> I'm unsure if you're creating the keyring file by hand.. but if you >> >> are, you can use this command to generate a file instead: >> >> >> >> ceph auth get-or-create client.manila -o /etc/ceph/ceph.client.manila.keyring >> >> You can use this ^ command to generate it and then make sure to copy >> it into the /etc/ceph folder that's mounted into the manila-share pod. >> >> >> >> >> >> >> >> >> On Wed, Jun 26, 2024 at 12:02 PM Alvaro Soto <alsotoes(a)gmail.com> wrote: >> >> > >> >> > Mmm wait, I believe I'm mistaken, I didn't read the entire config file. >> >> > Please omit my comment. >> >> > >> >> > On Wed, Jun 26, 2024, 12:54 PM Alvaro Soto <alsotoes(a)gmail.com> wrote: >> >> >> >> >> >> Hi again, >> >> >> It seems you are missing osd permission on manila user authorization: >> >> >> >> >> >> Allow manila user to read/write on osd's >> >> >> >> >> >> Cheers. >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Jun 26, 2024, 7:36 AM Shubham Kumar Yadav <shubham.kumar.yadav369(a)gmail.com> wrote: >> >> >>> >> >> >>> hello, >> >> >>> I'm trying to install manila in my openstack cloud but having problem with "Authorizing the driver to communicate with Ceph" >> >> >>> >> >> >>> 1 -> i have created a configmap with these confs and mounted it on manila-share pod >> >> >>> >> >> >>> [client.manila] >> >> >>> client mount uid = 0 >> >> >>> client mount gid = 0 >> >> >>> log file = /opt/stack/logs/ceph-client.manila.log >> >> >>> admin socket = /opt/stack/status/stack/ceph-$name.$pid.asok >> >> >>> keyring = /etc/ceph/manila.keyring >> >> >>> >> >> >>> >> >> >>> 2 -> then i have created a secret with client.manila keyring and attached it to the manila-share pod at >> >> >>> >> >> >>> keyring = /etc/ceph/manila.keyring >> >> >>> >> >> >>> 3 -> inside manila-share pod i see the logs >> >> >>> >> >> >>> 2024-06-03 09:00:53.682 6 INFO manila.share.drivers.cephfs.driver [None req-22cd7b29-a383-44cd-8cb8-1c639a3034dc - - - - - -] [CEPHFSNATIVE1] Ceph client found, connecting... >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager [None req-22cd7b29-a383-44cd-8cb8-1c639a3034dc - - - - - -] Error encountered during initialization of driver CephFSDriver@lab-11053-26006-ceph-2@cephfsnative1: manila.exception.ShareBackendException: [%(be)s] Ceph client failed to connect. >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager Traceback (most recent call last): >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 421, in rados_client >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager self._rados_client.connect() >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "rados.pyx", line 690, in rados.Rados.connect >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager rados.IOError: [errno 5] RADOS I/O error (error connecting to the cluster) >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager During handling of the above exception, another exception occurred: >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager Traceback (most recent call last): >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/manager.py", line 371, in _driver_setup >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager self.driver.do_setup(ctxt) >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 274, in do_setup >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager rados_client=self.rados_client, >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 424, in rados_client >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager raise exception.ShareBackendException( >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager manila.exception.ShareBackendException: [%(be)s] Ceph client failed to connect. >> >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager >> >> >>> 2024-06-03 09:00:53.714 6 DEBUG manila.utils [None req-22cd7b29-a383-44cd-8cb8-1c639a3034dc - - - - - -] Finished call to 'manila.share.manager.ShareManager.init_host.<locals>._driver_setup' after 2222.651(s), this was the 12th time calling it. log_it /var/lib/openstack/lib/python3.10/site-packages/tenacity/after.py:44 >> >> >>> 2024-06-03 09:00:53.714 6 DEBUG manila.utils [None req-22cd7b29-a383-44cd-8cb8-1c639a3034dc - - - - - -] Retrying manila.share.manager.ShareManager.init_host.<locals>._driver_setup in 600.0 seconds as it raised ShareBackendException: [%(be)s] Ceph client failed to connect.. log_it /var/lib/openstack/lib/python3.10/site-packages/tenacity/before_sleep.py:65 >> >> >>> >> >> >>> >> >> >>> 4 -> My ceph cluster is healthy >> >> >>> >> >> >>> 5 -> My manila confs look like (what could be wrong here)? >> >> >>> >> >> >>> conf: >> >> >>> manila: >> >> >>> DEFAULT: >> >> >>> debug: true >> >> >>> enabled_share_protocols: NFS,CIFS,CEPHFS >> >> >>> enabled_share_backends: cephfsnative1 >> >> >>> cephfsnative1: >> >> >>> driver_handles_share_servers: False >> >> >>> share_backend_name: CEPHFSNATIVE1 >> >> >>> share_driver: manila.share.drivers.cephfs.driver.CephFSDriver >> >> >>> cephfs_conf_path: /etc/ceph/ceph.conf >> >> >>> cephfs_protocol_helper_type: CEPHFS >> >> >>> cephfs_auth_id: manila >> >> >>> cephfs_cluster_name: rook-ceph ( my rook-ceph cluster name) >> >> >>> cephfs_filesystem_name: myfs (i created this fs manually) >> >> >>> >> >> >>> 6 -> Permissions for the user manila >> >> >>> >> >> >>> ceph auth get-or-create client.manila -o manila.keyring \ >> >> >>> mgr 'allow rw' \ >> >> >>> mon 'allow r' >> >> >>> >> >> >>> >> >> >>> 7 -> ceph --version >> >> >>> ceph version 17.2.6 (d7ff0d10654d2280e08f1ab989c7cdf3064446a5) quincy (stable) >> >> >>> >> >> >>> openstackhelm Manila Chart >> >> >>> name: manila >> >> >>> version: 0.1.7 >> >> >>> >> >> >>> 8 -> ceph -n client.manila fs ls >> >> >>> [errno 1] RADOS permission error (error connecting to the cluster) >> >> >>> (while it works with admin) >> >> >>> >> >> >>> Hope to hear from you soon with a solution >> >> >>> Thank you!

1 0

[manila] stuck at connecting ceph backend with manila
by Goutham Pacha Ravi 27 Jun '24

27 Jun '24

Hi, On Thu, Jun 27, 2024 at 12:26 AM Shubham Kumar Yadav <shubham.kumar.yadav369(a)gmail.com> wrote: > > Hi, these are the outputs you asked for > > 1 -> ls -l /etc/ceph > total 12 > -rw-r--r-- 1 root root 279 Jun 26 08:02 ceph.conf > -rw-r--r-- 1 root root 62 Jun 26 08:02 keyring > -rw-r--r-- 1 root root 92 Mar 4 20:27 rbdmap The manila keyring is missing here; Can you add it here and retry? > > > 2 -> ceph --verbose fs ls -n client.manila > parsed_args: Namespace(admin_socket=None, block=False, cephconf=None, client_id=None, client_name='client.manila', cluster=None, cluster_timeout=None, completion=False, help=False, input_file=None, output_file=None, output_format=None, period=1, setgroup=None, setuser=None, status=False, verbose=True, version=False, watch=False, watch_channel=None, watch_debug=False, watch_error=False, watch_info=False, watch_sec=False, watch_warn=False), childargs: ['fs', 'ls'] > [errno 1] RADOS permission error (error connecting to the cluster) > > 3 -> i created keyring using > > ceph auth get-or-create client.manila -o manila.keyring \ > mgr 'allow rw' \ > mon 'allow r' > > > Hope to hear from you soon > Thank you! > > > > On Thu, 27 Jun 2024 at 05:25, Goutham Pacha Ravi <gouthampravi(a)gmail.com> wrote: >> >> The client capabilities look correct; Can you paste the output of "ls >> -l /etc/ceph" from the manila-share pod? >> Also attempt to use "--verbose" with the Ceph CLI; maybe there'll be a >> helpful log: "ceph --verbose fs ls -n client.manila" >> >> I'm unsure if you're creating the keyring file by hand.. but if you >> are, you can use this command to generate a file instead: >> >> ceph auth get-or-create client.manila -o /etc/ceph/ceph.client.manila.keyring You can use this ^ command to generate it and then make sure to copy it into the /etc/ceph folder that's mounted into the manila-share pod. >> >> >> >> On Wed, Jun 26, 2024 at 12:02 PM Alvaro Soto <alsotoes(a)gmail.com> wrote: >> > >> > Mmm wait, I believe I'm mistaken, I didn't read the entire config file. >> > Please omit my comment. >> > >> > On Wed, Jun 26, 2024, 12:54 PM Alvaro Soto <alsotoes(a)gmail.com> wrote: >> >> >> >> Hi again, >> >> It seems you are missing osd permission on manila user authorization: >> >> >> >> Allow manila user to read/write on osd's >> >> >> >> Cheers. >> >> >> >> >> >> >> >> On Wed, Jun 26, 2024, 7:36 AM Shubham Kumar Yadav <shubham.kumar.yadav369(a)gmail.com> wrote: >> >>> >> >>> hello, >> >>> I'm trying to install manila in my openstack cloud but having problem with "Authorizing the driver to communicate with Ceph" >> >>> >> >>> 1 -> i have created a configmap with these confs and mounted it on manila-share pod >> >>> >> >>> [client.manila] >> >>> client mount uid = 0 >> >>> client mount gid = 0 >> >>> log file = /opt/stack/logs/ceph-client.manila.log >> >>> admin socket = /opt/stack/status/stack/ceph-$name.$pid.asok >> >>> keyring = /etc/ceph/manila.keyring >> >>> >> >>> >> >>> 2 -> then i have created a secret with client.manila keyring and attached it to the manila-share pod at >> >>> >> >>> keyring = /etc/ceph/manila.keyring >> >>> >> >>> 3 -> inside manila-share pod i see the logs >> >>> >> >>> 2024-06-03 09:00:53.682 6 INFO manila.share.drivers.cephfs.driver [None req-22cd7b29-a383-44cd-8cb8-1c639a3034dc - - - - - -] [CEPHFSNATIVE1] Ceph client found, connecting... >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager [None req-22cd7b29-a383-44cd-8cb8-1c639a3034dc - - - - - -] Error encountered during initialization of driver CephFSDriver@lab-11053-26006-ceph-2@cephfsnative1: manila.exception.ShareBackendException: [%(be)s] Ceph client failed to connect. >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager Traceback (most recent call last): >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 421, in rados_client >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager self._rados_client.connect() >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "rados.pyx", line 690, in rados.Rados.connect >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager rados.IOError: [errno 5] RADOS I/O error (error connecting to the cluster) >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager During handling of the above exception, another exception occurred: >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager Traceback (most recent call last): >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/manager.py", line 371, in _driver_setup >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager self.driver.do_setup(ctxt) >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 274, in do_setup >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager rados_client=self.rados_client, >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 424, in rados_client >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager raise exception.ShareBackendException( >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager manila.exception.ShareBackendException: [%(be)s] Ceph client failed to connect. >> >>> 2024-06-03 09:00:53.713 6 ERROR manila.share.manager >> >>> 2024-06-03 09:00:53.714 6 DEBUG manila.utils [None req-22cd7b29-a383-44cd-8cb8-1c639a3034dc - - - - - -] Finished call to 'manila.share.manager.ShareManager.init_host.<locals>._driver_setup' after 2222.651(s), this was the 12th time calling it. log_it /var/lib/openstack/lib/python3.10/site-packages/tenacity/after.py:44 >> >>> 2024-06-03 09:00:53.714 6 DEBUG manila.utils [None req-22cd7b29-a383-44cd-8cb8-1c639a3034dc - - - - - -] Retrying manila.share.manager.ShareManager.init_host.<locals>._driver_setup in 600.0 seconds as it raised ShareBackendException: [%(be)s] Ceph client failed to connect.. log_it /var/lib/openstack/lib/python3.10/site-packages/tenacity/before_sleep.py:65 >> >>> >> >>> >> >>> 4 -> My ceph cluster is healthy >> >>> >> >>> 5 -> My manila confs look like (what could be wrong here)? >> >>> >> >>> conf: >> >>> manila: >> >>> DEFAULT: >> >>> debug: true >> >>> enabled_share_protocols: NFS,CIFS,CEPHFS >> >>> enabled_share_backends: cephfsnative1 >> >>> cephfsnative1: >> >>> driver_handles_share_servers: False >> >>> share_backend_name: CEPHFSNATIVE1 >> >>> share_driver: manila.share.drivers.cephfs.driver.CephFSDriver >> >>> cephfs_conf_path: /etc/ceph/ceph.conf >> >>> cephfs_protocol_helper_type: CEPHFS >> >>> cephfs_auth_id: manila >> >>> cephfs_cluster_name: rook-ceph ( my rook-ceph cluster name) >> >>> cephfs_filesystem_name: myfs (i created this fs manually) >> >>> >> >>> 6 -> Permissions for the user manila >> >>> >> >>> ceph auth get-or-create client.manila -o manila.keyring \ >> >>> mgr 'allow rw' \ >> >>> mon 'allow r' >> >>> >> >>> >> >>> 7 -> ceph --version >> >>> ceph version 17.2.6 (d7ff0d10654d2280e08f1ab989c7cdf3064446a5) quincy (stable) >> >>> >> >>> openstackhelm Manila Chart >> >>> name: manila >> >>> version: 0.1.7 >> >>> >> >>> 8 -> ceph -n client.manila fs ls >> >>> [errno 1] RADOS permission error (error connecting to the cluster) >> >>> (while it works with admin) >> >>> >> >>> Hope to hear from you soon with a solution >> >>> Thank you!

1 0

Antelope: strange failure in VM migration from a Yoga HV to an Antelope one
by Michel Jouvin 27 Jun '24

27 Jun '24

Hi, In our Yoga -> Antelope upgrade, we have been able to live migrate active VMs from most Yoga HV to an Antelope one. In one case, the migration starts well but at the end of the disk migration, there is an "unexpected error" and the migration is canceled. I have not been able to find any more detailed information about the failure. In the source HV, nova-compute log says: ------------------- 2024-06-13 13:41:09.544 4108750 INFO nova.virt.libvirt.driver [req-565bd94e-9a3d-43b9-a42d-80ea6545c0a6 5c0b6777dafaad4f7a2e9d3b1959ff732468809f18ef35286eb123fb10865760 1b693dd6ab914fc0b5398f96e7866dd2 - 278da0eaa8cc4870a72e3a8abbf9a3f0 4828d76008524b798a4f5f632ba26adf] [instance: 81d8ce0d-3120-45ad-b8c7-c219638fbbdd] Migration running for 2804 secs, memory 100% remaining (bytes processed=0, remaining=0, total=0); disk 1% remaining (bytes processed=106548297728, remaining=863371264, total=107411668992). 2024-06-13 13:41:20.436 4108750 INFO nova.compute.resource_tracker [req-db52ee9a-b0e4-4ac1-83f6-f57600ccc275 - - - - -] [instance: 81d8ce0d-3120-45ad-b8c7-c219638fbbdd] Updating resource usage from migration 35e1a5e8-0f7d-4ff9-9075-c8da30649b4a 2024-06-13 13:41:45.678 4108750 INFO nova.virt.libvirt.driver [req-565bd94e-9a3d-43b9-a42d-80ea6545c0a6 5c0b6777dafaad4f7a2e9d3b1959ff732468809f18ef35286eb123fb10865760 1b693dd6ab914fc0b5398f96e7866dd2 - 278da0eaa8cc4870a72e3a8abbf9a3f0 4828d76008524b798a4f5f632ba26adf] [instance: 81d8ce0d-3120-45ad-b8c7-c219638fbbdd] Migration running for 2840 secs, memory 4% remaining (bytes processed=13900749654, remaining=691298304, total=16782270464); disk 0% remaining (bytes processed=107429101568, remaining=262144, total=107429363712). 2024-06-13 13:41:51.153 4108750 INFO nova.compute.manager [req-115e45f4-d8c5-43d7-ae70-1608818eaf70 - - - - -] [instance: 81d8ce0d-3120-45ad-b8c7-c219638fbbdd] VM Paused (Lifecycle Event) 2024-06-13 13:41:51.212 4108750 INFO nova.compute.manager [req-115e45f4-d8c5-43d7-ae70-1608818eaf70 - - - - -] [instance: 81d8ce0d-3120-45ad-b8c7-c219638fbbdd] During sync_power_state the instance has a pending task (migrating). Skip. 2024-06-13 13:41:51.390 4108750 INFO nova.compute.manager [req-115e45f4-d8c5-43d7-ae70-1608818eaf70 - - - - -] [instance: 81d8ce0d-3120-45ad-b8c7-c219638fbbdd] VM Resumed (Lifecycle Event) 2024-06-13 13:41:51.426 4108750 INFO nova.compute.manager [req-115e45f4-d8c5-43d7-ae70-1608818eaf70 - - - - -] [instance: 81d8ce0d-3120-45ad-b8c7-c219638fbbdd] During sync_power_state the instance has a pending task (migrating). Skip. 2024-06-13 13:41:51.772 4108750 ERROR nova.virt.libvirt.driver [req-565bd94e-9a3d-43b9-a42d-80ea6545c0a6 5c0b6777dafaad4f7a2e9d3b1959ff732468809f18ef35286eb123fb10865760 1b693dd6ab914fc0b5398f96e7866dd2 - 278da0eaa8cc4870a72e3a8abbf9a3f0 4828d76008524b798a4f5f632ba26adf] [instance: 81d8ce0d-3120-45ad-b8c7-c219638fbbdd] Migration operation has aborted 2024-06-13 13:41:51.774 4108750 ERROR nova.virt.libvirt.driver [req-565bd94e-9a3d-43b9-a42d-80ea6545c0a6 5c0b6777dafaad4f7a2e9d3b1959ff732468809f18ef35286eb123fb10865760 1b693dd6ab914fc0b5398f96e7866dd2 - 278da0eaa8cc4870a72e3a8abbf9a3f0 4828d76008524b798a4f5f632ba26adf] [instance: 81d8ce0d-3120-45ad-b8c7-c219638fbbdd] Live Migration failure: internal error: QEMU unexpectedly closed the monitor (vm='instance-00042fe6'): 2024-06-13T10:54:25.319005Z qemu-kvm: warning: Machine type 'pc-i440fx-rhel7.6.0' is deprecated: machine types for previous major releases are deprecated 2024-06-13 13:41:51.806 4108750 INFO nova.compute.manager [req-565bd94e-9a3d-43b9-a42d-80ea6545c0a6 5c0b6777dafaad4f7a2e9d3b1959ff732468809f18ef35286eb123fb10865760 1b693dd6ab914fc0b5398f96e7866dd2 - 278da0eaa8cc4870a72e3a8abbf9a3f0 4828d76008524b798a4f5f632ba26adf] [instance: 81d8ce0d-3120-45ad-b8c7-c219638fbbdd] Swapping old allocation on dict_keys(['0a7be64c-cff9-4fa7-93ac-ddd0a965e93a']) held by migration 35e1a5e8-0f7d-4ff9-9075-c8da30649b4a for instance 2024-06-13 13:41:52.882 4108750 WARNING nova.compute.manager [req-8c267aa3-29dc-43ec-9a1b-9c4ada34dd3f f0d2557b870a44fa90c98b507629407e 5cf79c1092c44348addf9bee098f138e - default default] [instance: 81d8ce0d-3120-45ad-b8c7-c219638fbbdd] Received unexpected event network-vif-unplugged-7446e7d3-a85d-4bd3-a609-decf5e7dd591 for instance with vm_state active and task_state None. 2024-06-13 13:41:55.758 4108750 WARNING nova.compute.manager [req-59c5fb1f-4223-4e14-90cf-c97bb0b9130a f0d2557b870a44fa90c98b507629407e 5cf79c1092c44348addf9bee098f138e - default default] [instance: 81d8ce0d-3120-45ad-b8c7-c219638fbbdd] Received unexpected event network-vif-plugged-7446e7d3-a85d-4bd3-a609-decf5e7dd591 for instance with vm_state active and task_state None. ----------------- It happens for all the VMs hosted by the source HV that have no link between them (not the same project) and whatever is the destination HV (same HW model) so I guess it has to do with the source HV. And there were no such problems when migrating VMs between the other HVs with the same HW model. Any idea where to look for details that may help to identify the problem? Best regards, Michel

1 2

答复: [largescale-sig]scaling story
by Alex Song (宋文平) 27 Jun '24

27 Jun '24

0 *H÷ 010 +0 *H÷ $Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Mohammed, The max number of conns for RabbitMQ is estimated through cacluating the conns of nova and cinder components. We have 3000 compute nodes, 3 control nodes and 15 cinder-volume nodes, We deploy rabbitmq on control nodes and use master-slave mode, the totally conns of RabbitMQ is almost 2w, so we set 2w for RabbitMQ configuration. Before deploying the SB relay, each ovn SB process needed to manage an average of 600+connections, the CPU usage is often 100% and the requests is slow processing. After adding the relay, each relay process handles about 60 connections, the total relay process is set to 10. After testing, each relay process has a low CPU usage and can process information quickly. -----é®ä»¶åä»¶----- åä»¶äºº: Thierry Carrez [mailto:thierry@openinfra.dev] åéæ¶éŽ: 2024å¹Ž6æ19æ¥ 17:29 æ¶ä»¶äºº: Alex Song (å®æå¹³) <songwenping(a)inspur.com> äž»é¢: Re: [largescale-sig]scaling story Hi Alex, Thanks for the great write up! I would love to see more of this. How did you adjust the max number of conns for RabbitMQ and for the relay I assume you used https://docs.ovn.org/en/latest/tutorials/ovn-ovsdb-relay.html <https://docs.ovn.org/en/latest/tutorials/ovn-ovsdb-relay.html> ? Thanks Mohammed *From: *Alex Song (å®æå¹³) <songwenping(a)inspur.com> *Date: *Wednesday, June 12, 2024 at 4:43â¯AM *To: *openstack-discuss(a)lists.openstack.org <openstack-discuss(a)lists.openstack.org> *Subject: *[largescale-sig]scaling story Hi everyone, we want to share our scaling story. Please refer the link: https://etherpad.opendev.org/p/large-scale-inspur <https://etherpad.opendev.org/p/large-scale-inspur> Thanks, Alex Song 0É0± xðáwIÊèë`{0 *H÷ 0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA0 170109092830Z 340511122004Z0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA0"0 *H÷ 0 «ä5ïc$Œ©æ'µ¯Þ6>úUKÛdÔ²Áe9Î~{BîÒLgD÷*wvVÊŠ/DýUj_xá\m/ óž=kÐ·éGÙœQ€ýx~Wùgk ÛÜøãÔ7É6NçÏ*?n°Ê²mhùè{Ã¯ôÌÆ 7üF-Î<@ÃÓÍ¬WçÅyåLZrF 6~føÈ×T~$0d¡ýL|zšøW=ötÚ%ýq,¥Ã~Ÿ"ÀýŸÑö2T,QÕÔ,dºÂÅ^§ÈôïåJ)ëVvp Ó£00 +7CA0U0Uÿ0ÿ0U^YŠŽLX`Nöµ¥9Š2Á5j0 +70# +7&a°$öz(¶o§K0 *H÷ daòYÙ~×ì×NÑ3ŽËlP±i!¿ýÅòsÝLºP;I4hžØþ¡L¶äŠJêà·Õ:1àEÕs®9UÛ:8Mh{Ä²ìºŒ£·ÚŒó×÷C_ŸhoÏúÆËYM&UØ³?9êèr·ìgP_÷mÇ#YÖpîw0º¹«0$p³jºnº¥¯/Ôä¬÷Ú ŠÖ5uþQÝ¶h(y¶ènnã%E,øú&Zâ"dKØ³ãi5VúP9±œ/ñ õkØŸsá/Xðï»¯€µ³O÷Í-ó¿Mè³3Óž{G(ªŸßŒG0C0+ ~+mçbí++0 *H÷ 0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA0 191128064731Z 241126064731Z010 &ò,dcom10 &ò,dlangchao10 &ò,dhome10Uæµªæœ®ä¿¡æ¯10U å®æå¹³1%0# *H÷ songwenping@inspur.com0"0 *H÷ 0 ã4ÒEd$i÷18#,åH~èyµþJRáLêg¡$@6vÔ<sâelPO4ýooXZç1¢iéÁ IòKjÚO§h;Rfùê7Ÿp¬ŒæäÝPòüÿ~æ E}é{có» (ù'+zÞ s ,!K£;û¥¶DEu1+ðÏ»õØÛähJjŸj']a¥Î·7¡õòhõßHŒ8QzÆ{ËÍ73>, ªí|gœ0y€Xv'ÚÊ ¬ÀO#)³°øÕM^œ¢VñóŸ¯ìFñ;µ5HŽù£Ã0¿0= +700.&+7ò©×z©=÷Ø\Jý&§Md\0)U%"0 ++ +7 0U 05 +7 (0&0 +0 +0 +7 0D *H÷ 7050*H÷ 0*H÷ 0+0 *H÷ 0UW 0²^qûìÇUã¡b[]s0U#0^YŠŽLX`Nöµ¥9Š2Á5j0U00ÿ ü ùºldap:///CN=INSPUR-CA,CN=JTCA2012,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=home,DC=langchao,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint:http://JTCA2012.home.langchao.com/CertEnroll/INSPUR-CA.crl0)+00±+0€ldap:///CN=INSPUR-CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=home,DC=langchao,DC=com?cACertificate?base?objectClass=certificationAuthority0a+0Uhttp://JTCA2012.home.langchao.com/CertEnroll/JTCA2012.home.langchao.com_INSPUR-CA.crt0IUB0@ & +7 songwenping@inspur.comsongwenping@inspur.com0 *H÷ §öãý+·>³â¿Xíe-÷¯[ÂÎ©É\ÃAæMà.U'ù||Wø$Šn' `9Ýµ¯éÉM^mz0Äð -AÒ¯×Tï+£§¡RbfzÆX#ùkY<ØDþxólõA%ÑøN¬×grÛÚ·ãF!GþóüVœÍ±Ð[ÏL®GÅ3€$ /DžÃiú_h|cI}DôþyªÉñ Ç}³W$_Äáy]ò±DÄ1(tr)6gêäÑæÄLd$!t{x±Z±·þÏeqmkþÒÒ÷r³ßxõ%lUÉÒ4d100p0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA~+mçbí++0 + ø0 *H÷ 1 *H÷ 0 *H÷ 1 240627081404Z0# *H÷ 1ŠÒ5KCuâ|!:¶!~ÏÚ/Ý0 +71r0p0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA~+mçbí++0*H÷ 1r p0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA~+mçbí++0 *H÷ 100 `He*0 `He0 *H÷ 0 `He0*H÷ 0 *H÷ @0+0 `He0 `He0 `He0 *H÷ Jû¡ûäž«$]ŽíijO yªLMÑ¢ÅúŸC±_U¶[1Jnl~/Aò¢\E gTŽ ENºÁ óª už6ÄµÕ/Ô/j/,ltµ~O¥Æù]Î0È9§DAªªC'8µG*9ÄíËüÛâèÔðHmá3ŽYËù*Ý'Ÿ¯ù§Ý,â9iâÙ2±×Á·ÞÌøtüoÙ wýÂ!7e&ß ëFÃ®T¢é3.k-îgøvc«nŠ*(G> óóFK°"óx aÙ Æ&?ûæxNJº~'Øü¯L

1 0

[Glance] Extending Specs Freeze Deadline by 1 week
by Pranali Deore 27 Jun '24

27 Jun '24

Hello All, As discussed in the last glance meeting [1] we are extending the glance specs freeze deadline by 1 week since we have 2 new specs up recently. Current Spec Freeze date (for Glance) : 5th July 2024 New Spec Freeze date (for Glance) : 12th July 2024 Please make sure your specs are updated before the new deadline. [1]: https://meetings.opendev.org/irclogs/%23openstack-meeting/%23openstack-meet… Thanks, Pranali Deore

1 0

[manila] stuck at connecting ceph backend with manila
by Shubham Kumar Yadav 26 Jun '24

26 Jun '24

hello, I'm trying to install manila in my openstack cloud but having problem with "*Authorizing the driver to communicate with Ceph*" *1 -> *i have created a configmap with these confs and mounted it on manila-share pod [client.manila]client mount uid = 0client mount gid = 0log file = /opt/stack/logs/ceph-client.manila.logadmin socket = /opt/stack/status/stack/ceph-$name.$pid.asokkeyring = /etc/ceph/manila.keyring *2 -> *then i have created a secret with client.manila keyring and attached it to the manila-share pod at keyring = /etc/ceph/manila.keyring *3 -> *inside manila-share pod i see the logs 2024-06-03 09:00:53.682 6 INFO manila.share.drivers.cephfs.driver [None req-22cd7b29-a383-44cd-8cb8-1c639a3034dc - - - - - -] [CEPHFSNATIVE1] Ceph client found, connecting... 2024-06-03 09:00:53.713 6 ERROR manila.share.manager [None req-22cd7b29-a383-44cd-8cb8-1c639a3034dc - - - - - -] Error encountered during initialization of driver CephFSDriver@lab-11053-26006-ceph-2@cephfsnative1: manila.exception.ShareBackendException: [%(be)s] Ceph client failed to connect. 2024-06-03 09:00:53.713 6 ERROR manila.share.manager Traceback (most recent call last): 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 421, in rados_client 2024-06-03 09:00:53.713 6 ERROR manila.share.manager self._rados_client.connect() 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "rados.pyx", line 690, in rados.Rados.connect 2024-06-03 09:00:53.713 6 ERROR manila.share.manager rados.IOError: [errno 5] RADOS I/O error (error connecting to the cluster) 2024-06-03 09:00:53.713 6 ERROR manila.share.manager 2024-06-03 09:00:53.713 6 ERROR manila.share.manager During handling of the above exception, another exception occurred: 2024-06-03 09:00:53.713 6 ERROR manila.share.manager 2024-06-03 09:00:53.713 6 ERROR manila.share.manager Traceback (most recent call last): 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/manager.py", line 371, in _driver_setup 2024-06-03 09:00:53.713 6 ERROR manila.share.manager self.driver.do_setup(ctxt) 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 274, in do_setup 2024-06-03 09:00:53.713 6 ERROR manila.share.manager rados_client=self.rados_client, 2024-06-03 09:00:53.713 6 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 424, in rados_client 2024-06-03 09:00:53.713 6 ERROR manila.share.manager raise exception.ShareBackendException( 2024-06-03 09:00:53.713 6 ERROR manila.share.manager manila.exception.ShareBackendException: [%(be)s] Ceph client failed to connect. 2024-06-03 09:00:53.713 6 ERROR manila.share.manager 2024-06-03 09:00:53.714 6 DEBUG manila.utils [None req-22cd7b29-a383-44cd-8cb8-1c639a3034dc - - - - - -] Finished call to 'manila.share.manager.ShareManager.init_host.<locals>._driver_setup' after 2222.651(s), this was the 12th time calling it. log_it /var/lib/openstack/lib/python3.10/site-packages/tenacity/after.py:44 2024-06-03 09:00:53.714 6 DEBUG manila.utils [None req-22cd7b29-a383-44cd-8cb8-1c639a3034dc - - - - - -] Retrying manila.share.manager.ShareManager.init_host.<locals>._driver_setup in 600.0 seconds as it raised ShareBackendException: [%(be)s] Ceph client failed to connect.. log_it /var/lib/openstack/lib/python3.10/site-packages/tenacity/before_sleep.py:65 *4 -> *My ceph cluster is healthy 5 -> My manila confs look like (what could be wrong here)? conf: manila: DEFAULT: debug: true enabled_share_protocols: NFS,CIFS,CEPHFS enabled_share_backends: cephfsnative1 cephfsnative1: driver_handles_share_servers: False share_backend_name: CEPHFSNATIVE1 share_driver: manila.share.drivers.cephfs.driver.CephFSDriver cephfs_conf_path: /etc/ceph/ceph.conf cephfs_protocol_helper_type: CEPHFS cephfs_auth_id: manila cephfs_cluster_name: rook-ceph ( my rook-ceph cluster name) cephfs_filesystem_name: myfs (i created this fs manually) *6 -> P*ermissions for the user manila ceph auth get-or-create client.manila -o manila.keyring \ mgr 'allow rw' \ mon 'allow r' *7 -> *ceph --version ceph version 17.2.6 (d7ff0d10654d2280e08f1ab989c7cdf3064446a5) quincy (stable) openstackhelm Manila Chart name: manila version: 0.1.7 8 -> *ceph -n client.manila fs ls* * [errno 1] RADOS permission error (error connecting to the cluster)* (while it works with admin) Hope to hear from you soon with a solution Thank you!

3 3

[dev][swift][account-reaper] Account with sharded bucket
by Thiago De Moraes Teixeira 26 Jun '24

26 Jun '24

Hi, I'm using swift-account-reaper for accounts with buckets in an unsharded state, and it looks fine, wiping the account. But when I try to wipe an account with sharded buckets, I encounter some problematic scenarios. First, when deleting the account, account-reaper lists objects from the sharded bucket, an empty list is returned from *direct_get_container* function, so the reaper interprets it as an empty bucket, and the delete fails with a 409 Conflict because objects exist inside the bucket. My second thought was to delete the account that holds shard buckets (i.e. .shards_AUTH_<project_id>) so the reaper will wipe this account. Then, with all buckets empty, they'll be deleted from the principal account (AUTH_<project_id>). But in this case, when the reaper tries to delete objects inside this account, all objects are not found because the object path used is "/.shards_AUTH_<project_id>/<bucket>-<hash>- <timestamp>-<shard_index>/<key>" instead of "/AUTH_<project_id>/ <bucket>/<key>". Am I doing something wrong in trying to delete this account? Or does account-reaper, in fact, not support sharded buckets? I'm exploring some patches to make it work, and I can volunteer to work on this fix if necessary. Thanks! -- _‘Esta mensagem é direcionada apenas para os endereços constantes no cabeçalho inicial. Se você não está listado nos endereços constantes no cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão imediatamente anuladas e proibidas’._ * **‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*

2 5

[neutron] Neutron CI meeting
by Rodolfo Alonso Hernandez 26 Jun '24

26 Jun '24

Hello Neutrinos: This is a personal request. I no longer can attend the CI meeting on Tuesdays at 15:00UTC. Due to the usually low attendance to this meeting, I would like to propose a new slot (if possible) to have this meeting weekly and be able to participate, as I've been doing during the last years. I will also raise this question in the next team meeting (Tuesdays at 14:00UTC). Just out of curiosity, I've created a poll with 3 slots (including the current one), to know what are your preferences. Please, vote only if you usually attend this meeting [1]. Thank you in advance. [1]https://doodle.com/meeting/participate/id/e3KAwKRe

1 0

[nova] Next THREE nova meetings are at risk
by Sylvain Bauza 25 Jun '24

25 Jun '24

Hey folks, Sorry for the very short notice, but I just realized that I can't attend : - today's nova meeting on June 25th (because of some appointment at the same time) - next week's nova meeting on July 2nd (because on PTO for that only day) - other week's nova meeting on July 9th (because of a one-week PTO) As a result, unless someone is proposing to chair one or other meeting, we may need to cancel them. As a reminder, we'll have a spec review day on July 1st, so please prepare your specs in advance. Anyone from the community fancy to run those meetings ? Thanks, -Sylvain

2 1

[openstack-ansible] Centralized logging
by MARCO MOSCATELLI 25 Jun '24

25 Jun '24

HI everyone I'm looking for a system to have centralized logging of all servers and services of an openstack deployment installed via openstack-ansible, have you some suggestions? Elasticsearch or Opensearch? Have you some reference for the installation with openstack-ansible? thanks Best regards Marco

1 0