June 2024 - openstack-discuss - lists.openstack.org

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

29 Jun '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 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

Warehouse failure
by ゞPositive î 29 Jun '24

29 Jun '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  

1 0

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

networking-onos plugin
by Ganesan, Sathya 28 Jun '24

28 Jun '24

Good Day, Is there an alternative integration available for ONOS and Openstack since networking-onos is archived? Sathya Ganesan Geico Tech | Data Center Core Network Engineering - SDN | sganesan(a)geico.com<mailto:sganesan@geico.com> | 240.478.2121 | M-F 9a-5:30p EST Sensitivity: Company-Internal ==================== This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message.

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

[swift] Weird log corruption or something more serious?
by Sam Morrison 27 Jun '24

27 Jun '24

Hi, We are debugging a weird issue with our swift cluster (currently running 2.29.2) We got a report from a user that they were getting upload failures and then sent us this from their logs: 2024-06-25 23:30:06,829 | swiftclient.service | ERROR | Object PUT failed: https://swift-host/v1/PROJECT_ID_A/prod_result/195e5e8e-334a-11ef-ba70-0a58… 401 Unauthorized [first 60 chars of response] b'<html><h1>Unauthorized</h1><p>This server could not verify t' (txn: txab25fcfcf3354bbbaf105-00667b52fe) Searching our logs for that transaction ID I found: 203.101.227.241 127.0.0.1 25/Jun/2024/23/30/06 PUT /v1/AUTH_PROJECT_ID_B/nexus-migration/nexus-data/blobs/default/content/vol-27/chap-25/6bc30bae-4f5e-40a8-bc63-096679af1a58.bytes HTTP/1.0 401 - rclone/v1.59.0%2Cpython-swiftclient-4.2.0 gAAAAABme1L7tlfE... - 131 - txab25fcfcf3354bbbaf105-00667b52fe - 0.0440 - - 1719358206.765954018 1719358206.809994936 0 Note this is a completely different project ID from our side, timestamp is correct too. We also have this: ERROR WSGI: code 400, message Bad request syntax ('\x89PNG') (txn: txab25fcfcf3354bbbaf105-00667b52fe) (client_ip: XX.XX.XX.XX) Upon further analysis we see this quite a lot, mostly from attempted hackers but lots from real users and lots seem to be related to rclone. Eg. Jun 27 08:24:46 swift-host proxy-server[70043]: ERROR WSGI: code 400, message Bad request syntax ('PUT /v1/AUTH_PROJECT_ID_B/nexus-migration/nexus-data/elasticsearch/nexus/nodes/0/indices/42b6a6a76dae683a647546ac02a6883108ac7df5/0/index/segments_4PUT /v1/AUTH_PROJECT_ID_B/nexus-migration/nexus-data/elasticsearch/nexus/nodes/0/indices/4db62ff1327dfe236d85b1dd1a6a9e8139e7e4cf/0/index/_67t.cfs HTTP/1.1') (txn: txd57a3d00bb1942c6a390e-00667c952a) (client_ip: XX.XX.XX.XX) Anyone know what is going on here? Thanks, Sam

1 0

答复: [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

[largescale-sig]scaling story
by Alex Song (宋文平) 26 Jun '24

26 Jun '24

Hi everyone, we want to share our scaling story. Please refer the link: https://etherpad.opendev.org/p/large-scale-inspur Thanks, Alex Song

4 3

[RALLY 4.1.0] Verifier reconfigure fails when in "no admin" mode
by Jean-François TALTAVULL 26 Jun '24

26 Jun '24

Hi All, I'm using a Rally (4.1.0) deployment with existing users and no admin credentials. So the command "rally env show" outputs "admin": null in the json and it's ok. But the problem is that the command "rally verify configure-verifier -reconfigure" fails with: "rally_openstack.common.credential.OpenStackCredential() argument after ** must be a mapping, not NoneType" I've been struggling with this error for a number of hours with no results :-( Any idea ? I looked for a known bug in launchpad but found nothing. Thanks, Jean-Francois

1 0

[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

[tc][all][monasca ] Retiring the Monasca project
by Ghanshyam Mann 25 Jun '24

25 Jun '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

5 12

[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

[neutron] Bug deputy report for week of June 17th
by Brian Haley 25 Jun '24

25 Jun '24

Hi, I was the stand-in Neutron bug deputy last week. Below is a short summary about the reported bugs. -Brian Critical bugs ------------- * https://bugs.launchpad.net/neutron/+bug/2069689 - broken out-of-tree modules due to the movement of wsgi module - n-d-r and vpnaas patches have merged - https://review.opendev.org/c/openstack/neutron/+/922185 necessary? High bugs --------- * https://bugs.launchpad.net/neutron/+bug/2069704 - rally jobs broken on unmaintantained/yoga and older branches - https://review.opendev.org/c/openstack/neutron/+/922230 * https://bugs.launchpad.net/neutron/+bug/2069831 - [eventlet] Deprecation of eventlet in Neutron - Rodolfo assigned to himself - All related patches will be tracked here Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/2069581 - [WSGI] Missing periodic workers when using WSGI server - https://review.opendev.org/c/openstack/neutron/+/922090 - Other patches still in-progress * https://bugs.launchpad.net/neutron/+bug/2069625 - [OVN] classless-static-route DHCP option is not sanitized and overrides default routes - https://review.opendev.org/c/openstack/neutron/+/922119 * https://bugs.launchpad.net/neutron/+bug/2069718 - [ovn] No connection to VM during live-migration - Seems valid, will discuss at weekly meeting * https://bugs.launchpad.net/neutron/+bug/2069744 - [FT] Run test_periodic_sync_routers_task tests serially - https://review.opendev.org/c/openstack/neutron/+/922218 Low bugs -------- * https://bugs.launchpad.net/neutron/+bug/2069595 - Neutron processes not following the same naming convention - Rodolfo assigned to himself, patches in progress Misc bugs --------- * https://bugs.launchpad.net/neutron/+bug/2069753 - [question] best practices for using RDMA? - Responded with some answers and ask for ML thread Wishlist bugs ------------- * None

1 0

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

25 Jun '24

hello, I'm trying to install manila in my openstack cloud but having problem *1 -> ceph -n client.manila fs subvolume ls myfs [errno 1] RADOS permission error (error connecting to the cluster)* this is what i get after running that not sure what permissions any idea? i had shared my confs earlier Hope to hear from you soon Thank you!

1 0

Migratekit: near-live migrations from VMware to OpenStack
by Mohammed Naser 25 Jun '24

25 Jun '24

Hi everyone! Over the last few weeks, I’ve been trying to solve the issue of migrations from VMware to OpenStack since they are very downtime heavy at the moment with the existing toolset. In addition, there seems to be no readily available open source projects that can handle the entire process from end to end. After a ton of research and leveraging awesome other open source projects (libnbd, ndbkit, etc), I was able to build a project that allows users to migrate from VMware to OpenStack with almost no downtime. https://github.com/vexxhost/migratekit You can find the documentation on how to use it in the README. I am hoping this is useful for others and that we start to have other people start contributing to the project and testing it in their environments. In all transparency, this was built against an ESXi 8.0 environment (no vCenter) using an evaluation license. We welcome those who have environments that they can test against and hope to increase the coverage for versions. 😊 Please try and give feedback and we hope to that folks find this useful and contribute back to have a fully open sourced way of migrating from VMware. There’s a lot more work to do, but this is a solid start at this point. 😊 Thanks, Mohammed

4 3

[publiccloud-sig] Reminder - next meeting June 26th - 0700 UTC
by Felix Kronlage-Dammers 25 Jun '24

25 Jun '24

Hi everyone, This Wednesday (June 26th, that is tomorrow) the next meeting of the public cloud sig is going to happen. We’ll be meeting at 0700 UTC here: https://meetpad.opendev.org/publiccloud-sig <https://meetpad.opendev.org/publiccloud-sig> See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG <https://wiki.openstack.org/wiki/PublicCloudSIG> See you on Wednesday! felix -- Felix Kronlage-Dammers Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com <mailto:fkr@osb-alliance.com>

1 0

[skyline][tc] Graduating skyline out of the "Emerging Projects" list
by Goutham Pacha Ravi 25 Jun '24

25 Jun '24

Hi, We were discussing in a recent TC meeting that Skyline seems to be ready to lose the "Emerging project" tag [1]. The arguments supporting it's graduation are: - The project is actively maintained, and has had consistent releases since the Zed release [2][3][4][5] - The project is being used in production cloud deployments [6] - Operators have requested skyline's inclusion in deployment and configuration management projects [7][8] Wu Wenxiang / Skyline team - is this assessment correct? If yes, are there any objections to removing Skyline from [1]? If it helps, the project team can re-assess the OpenStack project requirements we have [9] and work on any deficiencies. Thanks, On behalf of the OpenStack TC, Goutham Pacha Ravi OpenStack TC Chair [1] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [2] https://releases.openstack.org/zed/#skyline-apiserver [3] https://releases.openstack.org/antelope/#skyline-apiserver [4] https://releases.openstack.org/bobcat/#skyline-apiserver [5] https://releases.openstack.org/caracal/#skyline-apiserver [6] https://governance.openstack.org/tc/user_survey/analysis-2023.html#how-do-y… [7] https://review.opendev.org/q/topic:%22osa/skyline%22 [8] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

1 0