December 2023 - openstack-discuss

[neutron] Drivers meeting cancelled tomorrow
by Brian Haley 14 Dec '23

14 Dec '23

Hello Neutrinos: Due to the lack of agenda, Friday's drivers meeting is cancelled. Have a nice weekend! -Brian

1 0

[solum][tc][all] Solum project marked inactive by TC
by Jay Faulkner 14 Dec '23

14 Dec '23

OpenStack Community, The Technical Committee marked the solum project inactive[0] due to failing CI jobs and general lack of contribution. If you rely on solum, please take notice that without intervention, it will not be part of future OpenStack releases, including 2024.1 (Caracal). The only way for a project to leave inactive status is to become active again, and be removed from the inactive list, or to be retired from OpenStack. For more information, please see our documentation[1] on inactive projects. I encourage the OpenStack community to rally and support solum to bring it back into active status. If you are an operator and want more information on how to contribute and get this project going, please reply to this email and someone will be glad to help. Thank you, Jay Faulkner OpenStack TC Chair 0: https://review.opendev.org/c/openstack/governance/+/902624 1: https://governance.openstack.org/tc/reference/emerging-technology-and-inact…

1 0

[freezer][tc][all] Freezer marked inactive by TC
by Jay Faulkner 14 Dec '23

14 Dec '23

OpenStack Community, The Technical Committee marked the freezer project inactive[0] due to failing CI jobs and general lack of contribution. If you rely on freezer, please take notice that without intervention, it will not be part of future OpenStack releases, including 2024.1 (Caracal). The only way for a project to leave inactive status is to become active again, and be removed from the inactive list, or to be retired from OpenStack. For more information, please see our documentation[1] on inactive projects. I encourage the OpenStack community to rally and support freezer to bring it back into active status. If you are an operator and want more information on how to contribute and get this project going, please reply to this email and someone will be glad to help. Thank you, Jay Faulkner OpenStack TC Chair 0: https://review.opendev.org/c/openstack/governance/+/902623 1: https://governance.openstack.org/tc/reference/emerging-technology-and-inact…

1 0

[Thank You] OpenInfra Live: Large Scale Ops Deep Dive: Samsung SDS
by Kristin Barrientos 14 Dec '23

14 Dec '23

Hi everyone, Thanks for watching the latest Large Scale Ops Deep Dive episode with Dan Paik from Samsung, SDS. What a great way to wrap up OpenInfra Live for the year. In case you missed the episode, you can find it here: https://www.youtube.com/watch?v=RI9SwY8VdCY&t=1s Do you want to be on OpenInfra Live in 2024? Email me your pitch or fill out the form on ideas.openinfra.live <https://openinfrafoundation.formstack.com/forms/openinfralive>[1], and maybe we’ll see you on a future show! Thanks, Kristin Barrientos Marketing Coordinator OpenInfra Foundation [1] https://openinfrafoundation.formstack.com/forms/openinfralive

1 0

[blazar] Next IRC meeting cancelled
by Pierre Riteau 14 Dec '23

14 Dec '23

Hello, The next IRC meeting scheduled for December 28 is cancelled. We will meet again on January 11. I wish everyone a very happy holiday! Pierre Riteau (priteau)

1 0

[ironic] Why do we support RAID level 2?
by Dmitry Tantsur 14 Dec '23

14 Dec '23

Hi folks, I was going through our RAID support and noticed that we declare support for RAID level 2. Per wikipedia [1] it's an extremely rarely used level which offers little benefits. Does anyone remember why we use that? Will anyone cry if we drop it? My worry is officially supporting something that nobody can even test because of lack of hardware or real use case behind it. Dmitry [1] https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_2

2 1

[cinder]Cannot create volume from snapshot
by Nguyễn Hữu Khôi 14 Dec '23

14 Dec '23

Hello guys. I am using Openstack Yoga and Dell Powerstore 5000T When I create volume from a snapshot then I encounter this error cinder.volume.drivers.dell_emc.powerstore.client [req-3384117a-0832-4983-96aa-fd701d68c8eb 6371ebfe0fce499983b1f07e7c34bf6d 4f6902ccd37f4e8f8a1a910641845866 - - -] REST Response: 422 with data {"messages":[{"code":"0xE0A040010003","severity":"Error","message_l10n":"The clone cannot be created because the max number of clones: 32, in a family has been reached.","arguments":["32"]}]} ERROR cinder.volume.drivers.dell_emc.powerstore.client [req-3384117a-0832-4983-96aa-fd701d68c8eb 6371ebfe0fce499983b1f07e7c34bf6d 4f6902ccd37f4e8f8a1a910641845866 - - -] Failed to create clone volume-cc1fdd0b-8dd7-41a2-b63e-1f Do we have any guide about this? Or how we can increase the max number of clones? Thank you. Regards Nguyen Huu Khoi

3 6

[Octavia] Next weekly meetings cancelled
by Gregory Thiemonge 14 Dec '23

14 Dec '23

Hi Folks, As discussed yesterday during our weekly meeting, the next Octavia weekly meetings (Dec 20 and 27) are cancelled, the next meeting will be held on January 3rd. Thanks, Greg

1 0

[taskflow][all] Taskflow still using removed asyncore
by Thomas Goirand 14 Dec '23

14 Dec '23

Hi, As per this document: https://docs.python.org/3/whatsnew/3.12.html > Removed > asynchat and asyncore > > These two modules have been removed according to the schedule in > PEP 594, having been deprecated in Python 3.6. Use asyncio instead. > (Contributed by Nikita Sobolev in gh-96580.) Therefore, building the taskflow package (and many other packages that depends on it, like Cinder) fails. Can someone write a patch to get rid of the use of asyncore? Will using asincio instead fail because of our use of Eventlet? Cheers, Thomas Goirand (zigo)

3 2

RE: openstack-discuss Digest, Vol 62, Issue 44 Neutron - Issue Urgent
by Asma Naz Shariq 13 Dec '23

13 Dec '23

Hi Openstack Neutron Team, I have deployed Multinode cluster of Openstack through kolla-ansible zed release. The problem I am facing is instances created cannot pick any Ip addresses( Rather than loop back ip or ipv6 addresses) from the assigned networks which I have created provider and self-service flat network type. Hence, I may not be able to ping and ssh instance from the controller node and these instances won’t be able to connect to the internet. Can you guide me how to resolve these issues related to network connectivity so I may able to send you the required files to troubleshoot easily? Thanks -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Thursday, December 14, 2023 12:26 AM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 62, Issue 44 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. What are the correct auth caps for Ceph RBD clients of Cinder / Glance / Nova (Christian Rohmann) 2. Re: What are the correct auth caps for Ceph RBD clients of Cinder / Glance / Nova (Jonathan Rosser) 3. Re: [tripleo][ironic][wallaby] Partition Table: loop (Alexey Kashavkin) 4. Re: [all][tc][ptls] Eventlet: Python 3.12, and other concerning discoveries (Jay Faulkner) ---------------------------------------------------------------------- Message: 1 Date: Wed, 13 Dec 2023 18:00:46 +0100 From: Christian Rohmann <christian.rohmann(a)inovex.de> Subject: What are the correct auth caps for Ceph RBD clients of Cinder / Glance / Nova To: openstack-discuss <openstack-discuss(a)lists.openstack.org> Message-ID: <a65d9057-67a2-4ab0-a2b6-fe327d185f06(a)inovex.de> Content-Type: text/plain; charset=UTF-8; format=flowed Hey openstack-discuss, I am a little confused about correct and required Ceph authx permissions for the RBD clients in Cinder, Glance and also Nova: When Glance is requested to delete an image it will check if this image has depended children, see https://opendev.org/openstack/glance_store/src/commit/6f5011d1f05c99894fb8b…. The children of Glance images usually are (Cinder) volumes, which therefore live in a different RBD pool "volumes". But if such children do exist a 500 error is thrown by Glance API. There also is an bug about this issue on Launchpad [3]. Manually using the RBD client shows the same error: > # rbd -n client.glance -k /etc/ceph/ceph.client.glance.keyring -p > images children $IMAGE_ID > > 2023-12-13T16:51:48.131+0000 7f198cf4e640 -1 > librbd::image::OpenRequest: failed to retrieve name: (1) Operation not > permitted > 2023-12-13T16:51:48.131+0000 7f198d74f640 -1 librbd::ImageState: > 0x5639fdd5af60 failed to open image: (1) Operation not permitted > rbd: listing children failed: (1) Operation not permitted > 2023-12-13T16:51:48.131+0000 7f1990c474c0 -1 librbd::api::Image: > list_descendants: failed to open descendant b7078ed7ace50d from pool > instances:(1) Operation not permitted So it's a permission error. Following either the documentation of Glance [1] or Ceph [2] on configuring the ceph auth caps there is no mention of granting anything towards the volume pool to Glance. So this is what I currently have configured: > client.cinder > key: REACTED > caps: [mgr] profile rbd pool=volumes, profile rbd-read-only > pool=images > caps: [mon] profile rbd > caps: [osd] profile rbd pool=volumes, profile rbd-read-only > pool=images > > client.glance > key: REACTED > caps: [mgr] profile rbd pool=images > caps: [mon] profile rbd > caps: [osd] profile rbd pool=images > > client.nova > key: REACTED > caps: [mgr] profile rbd pool=instances, profile rbd > pool=images > caps: [mon] profile rbd > caps: [osd] profile rbd pool=instances, profile rbd > pool=images > When granting the glance client e.g. "rbd-read-only" to the volumes pool via: > > # ceph auth caps client.glance mon 'profile rbd' osd 'profile rbd > pool=images, profile rbd-read-only pool=volumes' mgr 'profile rbd > pool=images, profile rbd-read-only pool=volumes' > the error is gone. I am wondering through if this is really just a documentation bug (at OpenStack AND Ceph equally) and if Glance really needs read-only on the whole volumes pool or if there is some other capability that covers asking for child images. All in all I am simply wondering what the correct and least-privilege ceph auth caps for the RBD clients in Cinder, Glance and Nova would look like. Thanks Christian [1] https://docs.openstack.org/glance/latest/configuration/configuring.html#con… [2] https://docs.ceph.com/en/latest/rbd/rbd-openstack/#setup-ceph-client-authen… [3] https://bugs.launchpad.net/glance/+bug/2045158 ------------------------------ Message: 2 Date: Wed, 13 Dec 2023 17:40:44 +0000 From: Jonathan Rosser <jonathan.rosser(a)rd.bbc.co.uk> Subject: Re: What are the correct auth caps for Ceph RBD clients of Cinder / Glance / Nova To: openstack-discuss(a)lists.openstack.org Message-ID: <fb421a48-b0f6-4a6c-8d72-5b2ed8532b52(a)rd.bbc.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Hi Christain, If you dig through the various deployment tooling then you'll find things like https://opendev.org/openstack/openstack-ansible/src/branch/master/inventory… Hope this is helpful, Jonathan. On 13/12/2023 17:00, Christian Rohmann wrote: > Hey openstack-discuss, > > I am a little confused about correct and required Ceph authx > permissions for the RBD clients in Cinder, Glance and also Nova: > > When Glance is requested to delete an image it will check if this > image has depended children, see > https://opendev.org/openstack/glance_store/src/commit/6f5011d1f05c99894fb8b…. > The children of Glance images usually are (Cinder) volumes, which > therefore live in a different RBD pool "volumes". But if such children > do exist a 500 error is thrown by Glance API. There also is an bug > about this issue on Launchpad [3]. > > Manually using the RBD client shows the same error: > >> # rbd -n client.glance -k /etc/ceph/ceph.client.glance.keyring -p >> images children $IMAGE_ID >> >> 2023-12-13T16:51:48.131+0000 7f198cf4e640 -1 >> librbd::image::OpenRequest: failed to retrieve name: (1) Operation >> not permitted >> 2023-12-13T16:51:48.131+0000 7f198d74f640 -1 librbd::ImageState: >> 0x5639fdd5af60 failed to open image: (1) Operation not permitted >> rbd: listing children failed: (1) Operation not permitted >> 2023-12-13T16:51:48.131+0000 7f1990c474c0 -1 librbd::api::Image: >> list_descendants: failed to open descendant b7078ed7ace50d from pool >> instances:(1) Operation not permitted > > So it's a permission error. Following either the documentation of > Glance [1] or Ceph [2] on configuring the ceph auth caps there is no > mention of granting anything towards the volume pool to Glance. > So this is what I currently have configured: > >> client.cinder >> key: REACTED >> caps: [mgr] profile rbd pool=volumes, profile rbd-read-only >> pool=images >> caps: [mon] profile rbd >> caps: [osd] profile rbd pool=volumes, profile rbd-read-only >> pool=images >> >> client.glance >> key: REACTED >> caps: [mgr] profile rbd pool=images >> caps: [mon] profile rbd >> caps: [osd] profile rbd pool=images >> >> client.nova >> key: REACTED >> caps: [mgr] profile rbd pool=instances, profile rbd >> pool=images >> caps: [mon] profile rbd >> caps: [osd] profile rbd pool=instances, profile rbd >> pool=images >> > > When granting the glance client e.g. "rbd-read-only" to the volumes > pool via: >> >> # ceph auth caps client.glance mon 'profile rbd' osd 'profile rbd >> pool=images, profile rbd-read-only pool=volumes' mgr 'profile rbd >> pool=images, profile rbd-read-only pool=volumes' >> > the error is gone. > > > I am wondering through if this is really just a documentation bug (at > OpenStack AND Ceph equally) and if Glance really needs read-only on > the whole volumes pool or if there is some other capability that > covers asking for child images. > > > All in all I am simply wondering what the correct and least-privilege > ceph auth caps for the RBD clients in Cinder, Glance and Nova would > look like. > > > > Thanks > > > Christian > > > > > [1] > https://docs.openstack.org/glance/latest/configuration/configuring.htm > l#configuring-the-rbd-storage-backend > [2] > https://docs.ceph.com/en/latest/rbd/rbd-openstack/#setup-ceph-client-a > uthentication [3] https://bugs.launchpad.net/glance/+bug/2045158 > > > ------------------------------ Message: 3 Date: Thu, 14 Dec 2023 01:05:41 +0600 From: Alexey Kashavkin <akashavkin(a)gmail.com> Subject: Re: [tripleo][ironic][wallaby] Partition Table: loop To: Julia Kreger <juliaashleykreger(a)gmail.com> Cc: openstack-discuss(a)lists.openstack.org Message-ID: <0F672C26-BC74-4D16-92FC-292F1D2BF62F(a)gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BE0F9200-A2C4-458F-B2C4-31E6043ACAA2" Greetings Julia, Thank you so much for your reply and clarification. > On 12 Dec 2023, at 20:22, Julia Kreger <juliaashleykreger(a)gmail.com> wrote: > > Greetings Alexey, > > That would do it. Whenever we do not see a kernel/ramdisk with an image file, we assume it is a whole disk image, and as a result, we don't partition, we only write out what we've been provided. This is rooted in the image convention storage with Glance, because you need a kernel/ramdisk to boot a partition, but you can "just boot" a whole disk image. > > The disk utilities, in this specific case when you look at the disk, it thinks it is looking at a partition image on a loopback due to the lack of the partition table. > > That being said, whole disk images are the preferred path given you have greater flexibility in the partition/structure/layout of the deployed host. > > Hope that helps explain and provides the extra context. > > -Julia > > > > On Tue, Dec 12, 2023 at 2:56 AM Alexey Kashavkin <akashavkin(a)gmail.com <mailto:akashavkin@gmail.com>> wrote: >> I realized what was wrong in my case. I have a partition image, and I added the ramdisk and kernel path to 'baremetal_deployment.yaml'. This helped.

1 0