- openstack-discuss - lists.openstack.org

[SQLAlchemy 2.x][cloudkitty][ironic-inspector][masakari][murano][trove][sahara][senlin][vitrage][zaqar] No SQLA 2.x support in a few projects
by Thomas Goirand 20 Nov '23

20 Nov '23

Hi, As in Debian, a few packages need SQLAlchemy 2.x, I am working toward adding all SQLA 2.x patches as backport to Bobcat. So far, I managed to backport patches for Heat and Glance, and I'll work on Cinder and Manila next. However, a few packages are failing when using SQLAlchemy 2.x, as per the experimental pseudo-excuse page for sqlalchemy: https://qa.debian.org/excuses.php?experimental=1&package=sqlalchemy So, the list of packages is (in alphabetical order): - cloudkitty - ironic-inspector - masakari - murano - trove - sahara - senlin - vitrage - zaqar These projects need to urgently work toward supporting SQLAlchemy 2.x, both because SQLA 2 will be in distros, and because the OpenStack project requirements needs to move on and bump SQLA to 2.0. Is there anyone working on this? I'm especially interested having Cloudkitty fixed, since we use it in production, but I'm not sure I have the skills for it. Stephen, who wrote the patches for Cinder, Manila, Glance, Heat and Nova at least, doesn't have the time to work on these, he told me on IRC. Cheers, Thomas Goirand (zigo)

4 5

[neutron] Bug Deputy Report November 13-19
by Jakub Libosvar 20 Nov '23

20 Nov '23

Hi all, this is the bug report for Neutron for the week of November 13. There is nothing that requires immediate attention, one critical bug that is handled and about to merge the fix as of now. Critical ———— - Unit test jobs with neutron-lib master(3.9.0) failing https://bugs.launchpad.net/neutron/+bug/2043959 Assigned to: Yatin Fix proposed: https://review.opendev.org/c/openstack/neutron/+/901430 Medium ——— - Some init_router_port steps are unnecessary for new devices https://bugs.launchpad.net/neutron/+bug/2043558 Fix proposed: https://review.opendev.org/c/openstack/neutron/+/900553 Assigned to: Adam Oswick - list_ip_routes should only fetch needed devices https://bugs.launchpad.net/neutron/+bug/2043564 Fix proposed: https://review.opendev.org/c/openstack/neutron/+/900415 Assigned to: Adam Oswick - Creating subnet for exsiting external network is time-comsuming https://bugs.launchpad.net/neutron/+bug/2043761 Assigned to: Liu Fix proposed: https://review.opendev.org/c/openstack/neutron/+/901225 Duplicate ———— - [ovn] no need rpc notifier if no l2 agent https://bugs.launchpad.net/neutron/+bug/2043759 duplicate of https://bugs.launchpad.net/neutron/+bug/1992352

1 0

[publiccloud-sig] Reminder - next meeting November 22nd - 0800 UTC
by Felix Kronlage-Dammers 20 Nov '23

20 Nov '23

Hi everyone, this Wednesday the next meeting of the public cloud sig is going to happen. Since we do every other meeting as a videosession, we’ll be meeting at 0800 UTC here: https://conf.scs.koeln:8443/OIF-public-cloud-sig In parallel we will be on irc on #openstack-operators as well of course. Am very much looking forward to wednesday morning! :) felix -- Felix Kronlage-Dammers Product Owner IaaS & Operations Sovereign Cloud Stack 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

1 0

RE: openstack-discuss -Nova Compute - Error | Urgent
by Asma Naz Shariq 20 Nov '23

20 Nov '23

Hi Openstack Community, I am deploying Openstack zed release Multinode cluster with 1x Controller and 1x compute and 1x storage. At the time of deployment, I encountered a below error for failed to register the compute service: TASK [nova-cell: Fail if nova-compute service failed to register] *********************************** fatal: [X.X.X.X]: FAILED! => {"changed": false, "msg": "The Nova compute service failed to register itself on the following hosts: computenode-virtual-machine"} fatal: [X.X.X.X]: FAILED! => {"changed": false, "msg": "The Nova compute service failed to register itself on the following hosts: computenode-virtual-machine"} The logs in nova-compute.log at compute node state the ERROR: 2023-11-20 11:54:32.008 7 ERROR oslo. messaging._drivers.impl_rabbit [None req-f8176572-75bf-4c27-a9be-e096cb43e2e3 - - - - - -] Connection failed: [Errno 113] EHOSTUNREACH (retrying in 31.0 seconds): OSError: [Errno 113] EHOSTUNREACH. Can anyone guide me how to resolve this issue? Thanks -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Monday, November 20, 2023 10:16 AM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 61, Issue 70 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. Re: about magnum capi for production (Nguyễn Hữu Khôi) ---------------------------------------------------------------------- Message: 1 Date: Mon, 20 Nov 2023 12:16:11 +0700 From: Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> Subject: Re: about magnum capi for production To: Satish Patel <satish.txt(a)gmail.com> Cc: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Message-ID: <CABAODRfcEA38QRLCpr_DtC5Dbxmr2x=G9nD8hENptAdh0Z0QXg(a)mail.gmail.com> Content-Type: multipart/alternative; boundary="000000000000068859060a8e96ec" Hello guys. This is a doc which is about how to make Magnum CAPI to work with Openstack deployed by Kolla Ansible.. https://github.com/ngyenhuukhoi/openstack-note/blob/main/Magnum%20Cluster%2… Feel free to ask. If I can help, I will. Nguyen Huu Khoi On Mon, Nov 20, 2023 at 12:09 PM Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> wrote: > Hello. > It uses prebuild Ubuntu to provision k8s cluster, > > On Mon, Nov 20, 2023 at 11:47 AM Satish Patel <satish.txt(a)gmail.com> > wrote: > >> Hi Folks, >> >> Tell me if I am wrong. CAPI is just kubernetes images to build k8s >> clusters instead using coreOS and install a bunch of stuff via heat. >> In documentation all I can see are imported images. Reference doc: >> https://vexxhost.github.io/magnum-cluster-api/user/getting-started/ >> >> Do I need to install anything else to make it work? >> >> On Fri, Nov 17, 2023 at 11:30 AM Mohammed Naser <mnaser(a)vexxhost.com> >> wrote: >> >>> Thanks! Happy to see that it is working smoothly 😊 >>> >>> >>> >>> Appreciate any docs, comments or issues. >>> >>> >>> >>> *From: *Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Date: *Friday, November 17, 2023 at 8:57 AM >>> *To: *Mohammed Naser <mnaser(a)vexxhost.com> >>> *Cc: *OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject: *Re: about magnum capi for production >>> >>> Hello guys. >>> >>> >>> >>> I have successfully implemented Magnum CAPI on my openstack system. >>> My deployment tool for Openstack is Kolla-Ansible. It worked >>> greatly, I am testing with create, delete and resize k8s cluster. It >>> is smooth when compared with Heat Driver. I will make some docs for new users to use it. >>> >>> >>> >>> Thank you vexxhost.com and contributors for very nice production. >>> >>> >>> >>> I will keep testing and reporting to help it be much better in the >>> future. >>> >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Tue, Nov 14, 2023 at 5:50 AM Nguyễn Hữu Khôi < >>> nguyenhuukhoinw(a)gmail.com> wrote: >>> >>> Hello. >>> >>> I get it now; >>> >>> Thank you very much. >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Nov 13, 2023 at 11:20 PM Mohammed Naser >>> <mnaser(a)vexxhost.com> >>> wrote: >>> >>> Hi there, >>> >>> >>> Nope – it is simply a different driver, so if you try to create >>> Fedora CoreOS clusters – it’ll use the old heat driver. Otherwise, >>> it will use the Cluster API if the image is marked as Ubuntu >>> >>> >>> >>> Thanks! >>> >>> Mohammed >>> >>> >>> >>> *From: *Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Date: *Monday, November 13, 2023 at 1:58 AM >>> *To: *Mohammed Naser <mnaser(a)vexxhost.com> >>> *Cc: *OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject: *Re: about magnum capi for production >>> >>> Hello Mohammed, >>> >>> >>> >>> I found that >>> >>> >>> >>> >>> https://vexxhost.github.io/magnum-cluster-api/user/getting-started/# >>> creating >>> >>> >>> >>> I would like to know that if we use cluster api, does it overwrite >>> heat when deploying new k8s cluster from horizon? >>> >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Oct 30, 2023 at 7:49 PM Nguyễn Hữu Khôi < >>> nguyenhuukhoinw(a)gmail.com> wrote: >>> >>> Awesome, thank you so much! >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Oct 30, 2023 at 7:31 PM Mohammed Naser <mnaser(a)vexxhost.com> >>> wrote: >>> >>> Sounds good, thank you. >>> >>> >>> >>> We also have a channel on the Kubernetes Slack that is relatively >>> active if you need help — it’s in the README :) >>> >>> >>> >>> Thanks! >>> >>> Mohammed >>> >>> >>> >>> Get Outlook for iOS <https://aka.ms/o0ukef> >>> ------------------------------ >>> >>> *From:* Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Sent:* Monday, October 30, 2023 8:23:07 AM >>> *To:* Mohammed Naser <mnaser(a)vexxhost.com> >>> *Cc:* OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject:* Re: about magnum capi for production >>> >>> >>> >>> Hello. >>> >>> Thank you very much. I am planning to use Magnum CAPI for my system. >>> I will feedback later. >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Oct 30, 2023 at 7:03 PM Mohammed Naser <mnaser(a)vexxhost.com> >>> wrote: >>> >>> Hi there! >>> >>> >>> >>> It works out of the box since the goal is to have an API that is >>> compatible so that all the ecosystem tools such as Terraform, >>> Ansible, CLI, Horizon all continue to work just fine! >>> >>> >>> >>> We’ve even made some quality of life improvements to the Magnum >>> plugin like letting you download KUBECONFIG from it. >>> >>> >>> >>> Thanks >>> >>> Mohammed >>> >>> >>> >>> Get Outlook for iOS <https://aka.ms/o0ukef> >>> ------------------------------ >>> >>> *From:* Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Sent:* Monday, October 30, 2023 1:09:10 AM >>> *To:* Mohammed Naser <mnaser(a)vexxhost.com> >>> *Cc:* OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject:* Re: about magnum capi for production >>> >>> >>> >>> Hello, >>> >>> >>> >>> Thank you for your sharing, Could you tell me how we use it with >>> Horizon or we need custom Horizon to use Magnum CAPI. >>> >>> >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Oct 30, 2023 at 11:10 AM Mohammed Naser >>> <mnaser(a)vexxhost.com> >>> wrote: >>> >>> Hi there. >>> >>> >>> >>> We deploy this driver in production in our public cloud as well as >>> many private clouds and as part of Atmosphere and we’ve been fully >>> maintaining it on our side here. >>> >>> >>> >>> Let me know if you have any questions >>> >>> >>> >>> Thanks >>> >>> Mohammed >>> >>> >>> >>> Get Outlook for iOS <https://aka.ms/o0ukef> >>> ------------------------------ >>> >>> *From:* Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Sent:* Sunday, October 29, 2023 10:22:22 PM >>> *To:* OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject:* about magnum capi for production >>> >>> >>> >>> Hello guys. >>> >>> Could you share with me some experience about using Magnum CAPI in >>> production? >>> >>> >>> >>> https://github.com/vexxhost/magnum-cluster-api >>> >>> >>> >>> Thank you so much. >>> >>> >>> Nguyen Huu Khoi >>> >>>

2 1

kolla-toolbox problem in multinode deploy
by Bursztynowski Dariusz 20 Nov '23

20 Nov '23

Hello, I'm facing a problem with kolla-toolbox while deploying zed-ubunu-jammy-aarch64 on a Raspberry Pi cluster using kolla-ansible. I 've built the images myself (on Raspbbery Pi) using kolla-build because images for Ubuntu-aarch64 were missing in standard repos (for Debian/aarch64, stuff installs from quay.io and works fine, but wanted to try out Ubuntu). The error can be seen at the very end of a fragment of the ansible log pasted below. As seen, images in my local repo are reachable (fluentd & kolla-toolbox restart succesfully). But in task "Initializing kolla-toolbox container" three hosts fail with the notification "Container xyz is restarting, wait until the container is running", while the fourth one gives "unable to upgrade to tcp, received 409". Interestingly, in a preceding task "Ensuring config directories have correct owner and permission" (the very first part of the log below), kolla-toolbox check is skipped. I can provide more data, create a bug report in appropriate place, etc. But please instruct me what and where. Best regards, Darek TASK [common : Ensuring config directories have correct owner and permission] ************************************************************************************************ ok: [ost64] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) ok: [ost61] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) skipping: [ost64] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) skipping: [ost61] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) ok: [ost62] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) skipping: [ost62] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) ok: [ost63] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) skipping: [ost63] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) ok: [ost64] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) ok: [ost61] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) ok: [ost62] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) ok: [ost63] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) TASK [common : Copy rabbitmq-env.conf to kolla toolbox] ********************************************************************************************************************** changed: [ost61] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/rabbitmq-env.conf.j2) changed: [ost64] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/rabbitmq-env.conf.j2) changed: [ost62] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/rabbitmq-env.conf.j2) changed: [ost63] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/rabbitmq-env.conf.j2) TASK [common : Copy rabbitmq erl_inetrc to kolla toolbox] ******************************************************************************************************************** changed: [ost64] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/erl_inetrc.j2) changed: [ost61] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/erl_inetrc.j2) changed: [ost62] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/erl_inetrc.j2) changed: [ost63] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/erl_inetrc.j2) TASK [common : Check common containers] ************************************************************************************************************************************** changed: [ost62] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) changed: [ost61] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) changed: [ost64] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) changed: [ost63] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) changed: [ost64] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) changed: [ost61] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) changed: [ost62] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) changed: [ost63] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) changed: [ost61] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) changed: [ost62] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) changed: [ost64] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) changed: [ost63] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) TASK [common : Creating log volume] ****************************************************************************************************************************************** ok: [ost64] ok: [ost61] ok: [ost62] ok: [ost63] TASK [common : Link kolla_logs volume to /var/log/kolla] ********************************************************************************************************************* changed: [ost64] changed: [ost61] changed: [ost62] changed: [ost63] TASK [common : Flush handlers] *********************************************************************************************************************************************** RUNNING HANDLER [common : Restart fluentd container] ************************************************************************************************************************* changed: [ost63] changed: [ost64] changed: [ost62] changed: [ost61] RUNNING HANDLER [common : Restart kolla-toolbox container] ******************************************************************************************************************* changed: [ost62] changed: [ost61] changed: [ost63] changed: [ost64] RUNNING HANDLER [common : Initializing toolbox container using normal user] ************************************************************************************************** fatal: [ost62]: FAILED! => {"changed": false, "cmd": ["docker", "exec", "-t", "kolla_toolbox", "ansible", "--version"], "delta": "0:00:00.064846", "end": "2023-11-19 21:46:19.187519", "msg": "non-zero return code", "rc": 1, "start": "2023-11-19 21:46:19.122673", "stderr": "Error response from daemon: Container 34d4dcc029d807cb70061bcab3f21e1980ec2541b6e116764dab22917d1ba602 is restarting, wait until the container is running", "stderr_lines": ["Error response from daemon: Container 34d4dcc029d807cb70061bcab3f21e1980ec2541b6e116764dab22917d1ba602 is restarting, wait until the container is running"], "stdout": "", "stdout_lines": []} fatal: [ost61]: FAILED! => {"changed": false, "cmd": ["docker", "exec", "-t", "kolla_toolbox", "ansible", "--version"], "delta": "0:00:00.170840", "end": "2023-11-19 21:46:19.383867", "msg": "non-zero return code", "rc": 1, "start": "2023-11-19 21:46:19.213027", "stderr": "Error response from daemon: Container fbe3a84809b7b5e23dbc84e896735bcc8c72fbd300b53637061bd305a6bd45eb is restarting, wait until the container is running", "stderr_lines": ["Error response from daemon: Container fbe3a84809b7b5e23dbc84e896735bcc8c72fbd300b53637061bd305a6bd45eb is restarting, wait until the container is running"], "stdout": "", "stdout_lines": []} fatal: [ost63]: FAILED! => {"changed": false, "cmd": ["docker", "exec", "-t", "kolla_toolbox", "ansible", "--version"], "delta": "0:00:00.422087", "end": "2023-11-19 21:46:19.579842", "msg": "non-zero return code", "rc": 1, "start": "2023-11-19 21:46:19.157755", "stderr": "Error response from daemon: Container 2b8c1c77cd75d8780ad358407178d0e8d431e22885fc0f58ae1e08e746928d9d is restarting, wait until the container is running", "stderr_lines": ["Error response from daemon: Container 2b8c1c77cd75d8780ad358407178d0e8d431e22885fc0f58ae1e08e746928d9d is restarting, wait until the container is running"], "stdout": "", "stdout_lines": []} fatal: [ost64]: FAILED! => {"changed": false, "cmd": ["docker", "exec", "-t", "kolla_toolbox", "ansible", "--version"], "delta": "0:00:00.693630", "end": "2023-11-19 21:46:19.859925", "msg": "non-zero return code", "rc": 1, "start": "2023-11-19 21:46:19.166295", "stderr": "unable to upgrade to tcp, received 409", "stderr_lines": ["unable to upgrade to tcp, received 409"], "stdout": "", "stdout_lines": []}

1 1

[release] Release countdown for week R-19, Nov 20-24
by Herve Beraud 17 Nov '23

17 Nov '23

Development Focus ----------------- We are now past the Caracal-1 milestone. Teams should now be focused on feature development. General Information ------------------- Our next milestone in this development cycle will be Caracal-2, on January 11, 2024. This milestone is when we freeze the list of deliverables that will be included in the 2024.1 Caracal final release, so if you plan to introduce new deliverables in this release, please propose a change to add an empty deliverable file in the deliverables/caracal directory of the openstack/releases repository. Now is also generally a good time to look at bugfixes that were introduced in the master branch that might make sense to be backported and released in a stable release. If you have any question around the OpenStack release process, feel free to ask on this mailing-list or on the #openstack-release channel on IRC. Upcoming Deadlines & Dates -------------------------- Caracal-2 Milestone: January 11, 2024 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[kolla-ansible][cinder]Backend problems
by Franck VEDEL 17 Nov '23

17 Nov '23

Hi, I come back to a point that caused me a big problem, because I would like to understand something that I did not do correctly. I have a lab with an Openstack (2023.1, kolla-ansible, ubuntu 22-04, 2 nodes) and to show that it works, I start with an LVM backend. Everything is working. I'm adding a Ceph (Pacific) cluster and want to switch from LVM backend to CEPH. If we edit the globals.yml file and make the changes, then the "deploy" command, the LVM backend is still in the list of backends. If we restart the cinder containers, same thing. If we do "stop" then "deploy": same thing. I had to do "stop", "destroy", "deploy" to no longer have the LVM backend but only the CEPH backend. My question is therefore the following: what should we do in this situation? Is there a solution to easily no longer take into account a backend? Thansk for your help Franck

2 2

[kolla][masakari] Deprecating Masakari Support in Kolla-Ansible
by Michał Nasiadka 17 Nov '23

17 Nov '23

Hello, Since the Kolla-Ansible CI jobs for Masakari using 2023.2 have been failing [1] due to some time - we are deprecating Masakari support in Kolla/Kolla-Ansible. As I can see - even the OpenStack bot patches have not been merged in 2023.2 branch [2]. If there is anybody willing to go the extra mile of reviving Masakari stable/2023.2 branch - please reach out - ideally by commenting on the deprecation patch in Gerrit [3]. [1]: https://zuul.opendev.org/t/openstack/builds?job_name=kolla-ansible-ubuntu-m… [2]: https://review.opendev.org/q/project:openstack/masakari+is:open+branch:stab… [3]: https://review.opendev.org/c/openstack/kolla-ansible/+/901193

1 0

[neutron] Drivers meeting cancelled next two weeks
by Brian Haley 16 Nov '23

16 Nov '23

Hello Neutrinos: Due to the lack of agenda, Friday's drivers meeting is cancelled. Have a nice weekend! Also canceling next week's since with the US Thanksgiving holiday we will likely not have quorum. -Brian

1 0

openstack: how can you remove volumen from postgres database on openstack controller?
by kjme001＠gmail.com 16 Nov '23

16 Nov '23

Hello, I have a problem with the volume, I can't delete it, it's still in the deleting state how can you remove volumen from postgres database on openstack controller? Thank you for your help

1 0

[neutron] How to divide a provider network into address segments for different projects to use
by 韩光宇 16 Nov '23

16 Nov '23

Hi, I have a victoria cluster. And all node have two nic. Same to neutron doc[1], one nic is management interface, other is provider interface. Assuming provider network is same as the example in the Neutron deployment doc, which is the 203.0.113.0/24 with gateway 203.0.113.1. I hope use different address segment for different project. For example: project_A: 203.0.113.11,203.0.113.30 project_B: 203.0.113.31,203.0.113.60 project_C: 203.0.113.61,203.0.113.90 I am currently considering one method: Creating different VLAN networks for different projects, but it requires configuring the physical switch ports as trunks. Is there any other way to achieve this? I would prefer to use a flat network. I will appreciate for any help. Best regards, Han Guangyu [1]: https://docs.openstack.org/neutron/latest/install/environment-networking-ob…

1 0

[Glance] Cancelling Weekly Meeting - 16th Nov
by Mridula Joshi 16 Nov '23

16 Nov '23

Hello All, Cancelling today's weekly meeting as most of the team members are not around for the meeting. See you next week ! Thanks, Mridula Joshi

1 0

[cinder] Festival of XS reviews (17 Nov)
by Rajat Dhasmana 16 Nov '23

16 Nov '23

Hello Argonauts, We will be having our monthly festival of reviews tomorrow i.e. 17th November (Friday) from 1400-1600 UTC. Following are the details: Date: 17th November, 2023 Time: 1400-1600 UTC Meeting link: https://meet.google.com/jqg-eigw-rku etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews Thanks Rajat Dhasmana

1 0

openstack: aborted: Failed to allocate the network(s), not rescheduling.].
by kjme001＠gmail.com 16 Nov '23

16 Nov '23

when creating a new instance I get an error: aborted: Failed to allocate the network(s), not rescheduling.]. Can anyone tell me where to look for the problem? Regards

3 2

RE: openstack-discuss Digest, Vol 61, Issue 61- Nova- Compute Service Issue
by Asma Naz Shariq 16 Nov '23

16 Nov '23

Hello Openstack Team, I have deployed openstack zed release with multinode cluster through kolla-ansible controller with 1x storage, 1x compute node. The nova-compute service failed to register itself on the compute-host as attached; due to which there encounters an error of no availability zone for an instance to launch. Can any one guide me how to resolve this nova service issues. -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Thursday, November 16, 2023 2:15 AM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 61, Issue 61 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. Re: [kolla-ansible][cinder-schedule] Problem between Ceph and cinder-schedule (Franck VEDEL) 2. Re: Re: [keystone] temporary workaround for deprecated _member_ role? (Michael Knox) 3. openstack: aborted: Failed to allocate the network(s), not rescheduling.]. (kjme001(a)gmail.com) ---------------------------------------------------------------------- Message: 1 Date: Wed, 15 Nov 2023 21:33:15 +0100 From: Franck VEDEL <franck.vedel(a)univ-grenoble-alpes.fr> Subject: Re: [kolla-ansible][cinder-schedule] Problem between Ceph and cinder-schedule To: Alan Bishop <abishop(a)redhat.com> Cc: openstack-discuss(a)lists.openstack.org Message-ID: <63B87539-94A5-4CA5-A6CA-9CB67124EAEF(a)univ-grenoble-alpes.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_880E21AE-FC09-43C2-8C33-2E2670B2D035" Alan ! Thanks a lot…. I had doubts about the last config because I only wanted to use the Ceph cluster, but cinder-scheduler was looking for a backend which it could not find. But the cluster was functional so: kolla-ansible -i multinode stop …..destroy…. deploy…. post-deploy…. init-runonce…. Et VOILA. This reset all configurations, adds and rollbacks to 0. And it works ! Thanks!! Franck > Le 15 nov. 2023 à 15:43, Alan Bishop <abishop(a)redhat.com> a écrit : > > > > On Wed, Nov 15, 2023 at 6:32 AM Franck VEDEL <franck.vedel(a)univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote: >> Hi Pierre >> Maybe I found something: >> In the container « cinder_volume », there is a file >> /etc/ceph/ceph.conf But, no /etc/ceph/ceph.conf file in « cinder_scheduler » container. >> I think it’s my problem !! > > Sorry, but the scheduler does not require access to /etc/ceph files. I > think you need to review the scheduler logs to see why it concluded > there are no available c-vol backends. Since you are able to create a volume, I assume the ceph backend is "up," but it would also be good to verify it remains up, especially during the time when you're trying to create a volume from an image. > > Alan > >> but why ? >> What is the option in globals.yml ? >> Or maybe there is something to add in /etc/kolla/config/cinder/ >> >> I have this (the last try): >> >> >> enable_cinder: "yes" >> enable_cinder_backup: "no" >> enable_cinder_backend_lvm: "no" >> external_ceph_cephx_enabled: "yes" >> >> # Glance >> ceph_glance_keyring: "ceph.client.glance.keyring" >> ceph_glance_user: "glance" >> ceph_glance_pool_name: "images" >> # Cinder >> ceph_cinder_keyring: "ceph.client.cinder.keyring" >> ceph_cinder_user: "cinder" >> ceph_cinder_pool_name: "volumes" >> >> #ceph_cinder_backup_keyring: "ceph.client.cinder-backup.keyring" >> #ceph_cinder_backup_keyring: "ceph.client.cinder.keyring" >> #ceph_cinder_backup_user: "cinder" >> #ceph_cinder_backup_user: "cinder-backup" >> #ceph_cinder_backup_pool_name: "backups" >> # Nova >> #ceph_nova_keyring: "{{ ceph_cinder_keyring }}" >> ceph_nova_keyring: "ceph.client.nova.keyring" >> ceph_nova_user: "nova" >> ceph_nova_pool_name: "vms" >> >> # Configure image backend. >> glance_backend_ceph: "yes" >> >> # Enable / disable Cinder backends >> cinder_backend_ceph: "yes" >> >> # Nova - Compute Options >> ######################## >> nova_backend_ceph: "yes" >> >> >> Thanks a lot >> >> >> >> Franck >> >> >>> Le 15 nov. 2023 à 09:54, Pierre Riteau <pierre(a)stackhpc.com <mailto:pierre@stackhpc.com>> a écrit : >>> >>> Hi Franck, >>> >>> It would help if you could share more details about the error (check both cinder-scheduler and cinder-volume logs). >>> >>> Do you have capabilities to access the images pool (presumably what is used by Glance) on your client.cinder user? >>> >>> Best wishes, >>> Pierre Riteau (priteau) >>> >>> On Wed, 15 Nov 2023 at 09:50, Franck VEDEL <franck.vedel(a)univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote: >>>> Good morning, >>>> I'll come back for help, thanks in advance. >>>> I am testing an Openstack 2023.1/Ceph Pacific environment. >>>> The cluster works, and from Horizon for example, if I create a simple volume, it works normally, it is placed in the "volumes" pool in the Ceph cluster, exactly as expected. >>>> >>>> if I create a volume from an image, ERROR cinder-schedule. >>>> In the cinder_volume and cinder_scheduler containers, same settings in cinder.conf. >>>> >>>> Before continuing to find out what the error could be, could there be a problem between Antelope (2023.1) and Ceph Pacific? (I'm on Ubuntu 22.04). >>>> >>>> Franck >>>> >>>> >>>> >>

1 0

[kolla-ansible][cinder-schedule] Problem between Ceph and cinder-schedule
by Franck VEDEL 16 Nov '23

16 Nov '23

Good morning, I'll come back for help, thanks in advance. I am testing an Openstack 2023.1/Ceph Pacific environment. The cluster works, and from Horizon for example, if I create a simple volume, it works normally, it is placed in the "volumes" pool in the Ceph cluster, exactly as expected. if I create a volume from an image, ERROR cinder-schedule. In the cinder_volume and cinder_scheduler containers, same settings in cinder.conf. Before continuing to find out what the error could be, could there be a problem between Antelope (2023.1) and Ceph Pacific? (I'm on Ubuntu 22.04). Franck

4 8

[cinder][ops] Deprecating vmdk volume driver
by Takashi Kajinami 15 Nov '23

15 Nov '23

Hello, # This is similar to my previous email[1] but this one is for a different component. Cinder has provided the following two volume drivers to manage volumes in VMWare product. VMwareVcVmdkDriver for VMWare vCenter server VMwareVStorageObjectDriver for VMWare VStorageObject These drivers may be useful for OpenStack deployments using VMWare hypervisors. However the vmware api virt driver is being removed during this cycle, and this use case is no longer supported. I'm sending this email to hear if anyone is using these volume drivers WITHOUT the vmware api virt driver. If no, then I'll propose deprecating these drivers in 2024.1 release, and remove these in 2024.2. In case you have any concerns (or agree with the plan) then please reply to this thread (or to me directly if needed). Thank you, Takashi [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

1 0

Cinder Bug Report 2023-11-15
by Jon Bernard 15 Nov '23

15 Nov '23

Hello Argonauts, Cinder Bug Meeting Etherpad <https://etherpad.opendev.org/p/cinder-bug-squad-meeting> There are exactly 0 new bugs this week, so no bug meeting today! Thanks, -- Jon

1 0

[largescale-sig] Next meeting: Nov 15, 8utc
by Thierry Carrez 15 Nov '23

15 Nov '23

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 8UTC, our EU+APAC-friendly time. Note that in some parts of the world, DST means that that meeting will be one hour earlier than usual. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20231115T08 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Thanks, -- Thierry Carrez (ttx)

1 1

[tc][releases][ptl][all] 'Unmaintained' branch update
by Brian Rosmaita 15 Nov '23

15 Nov '23

Hello Stackers, I'm sure you saw Elod's email eariler this week [0] calling for final releases from stable/yoga in preparation for its transition to 'Unmaintained' status. In addition to stable/yoga, the TC resolution [1] specified that the three most recent Extended Maintenance branches would also transition to 'Unmaintained', and branches older than that can be deleted. The TC and the release team have had some discussions over the past two weeks [2,3,4,5], and we are closing in on a consensus on how the proposal described in the 2023-07024 resolution should work. This is how it's looking: (1) branches ineligible for Unmaintained status These are stable/ussuri and stable/train. The release team will use the current tooling to generate the patches proposing the ussuri-eol and train-eol tags; teams will have a grace period to get any final changes merged; after the -eol tags are made, the branches will be deleted. (2) transitioning a branch out of Maintained status This is stable/yoga. Elod has already sent the reminder email [0] for project teams to propose a release patch if there's a reason to do a final release. The release team is working on tooling that will mark the HEAD of stable/yoga with yoga-eom (for "end of maintenance"), delete the stable/yoga branch, and then cut the unmaintained/yoga branch based on the yoga-eom tag. There will be a grace period for the community to decide whether the branch should be kept in Unmaintained status or deleted, as described in [1]. Eventually (either when the grace period expires, or later, when there is no longer interest in keeping unmaintained/yoga around), the HEAD will be tagged yoga-eol and the branch deleted. (3) transitioning current eligible Extended Maintenance branches to Unmaintained status These are stable/xena, stable/wallaby, and stable/victoria. Ericsson has expressed interest in keeping victoria in Unmaintained status. Subject to the guidelines in [1], wallaby, xena, and yoga will therefore be kept in Unmaintained status as well. Eventually, consistent with [1], these branches will be tagged $series-eol and deleted. For more details about (1)-(3) above, see the discussion in [6]. The current patch to the Project Team Guide [7] will be updated shortly to reflect the discussion in [6]. (4) amendment to the Unmaintained branch resolution The original plan in [1] was for there to be a $project-unmaintained-core Gerrit group for each OpenStack project that would have +2/+W powers on the unmaintained/$series branches. This would entail changes in the Gerrit ACL config files for all projects plus populating all the Gerrit groups. I've put up an amendment [8] to the resolution that would instead establish a single openstack-unmaintained-core Gerrit group that would have +2/+W powers over all the unmaintained/* branches in the openstack namespace. Projects that would prefer to stick with the original proposal and have tighter control over their unmaintained/* branches can still do so; they'll have to patch the appropriate Gerrit ACL config file(s) for their project and populate the $project-unmaintained-core group. Note that except for the Amendment mentioned in (4), this email only provides details about how [1] is to be implemented; it does not change the nature of the Unmaintained branch proposal that was adopted by the TC back in July 2023. If you have questions or comments, please reply to the openstack-discuss mailing list, or leave comments on [7] and [8]. [0] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [1] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branc… [2] https://meetings.opendev.org/meetings/tc/2023/tc.2023-10-31-18.00.log.html#… [3] https://meetings.opendev.org/meetings/tc/2023/tc.2023-11-07-18.00.log.html#… video meeting recording: https://www.youtube.com/watch?v=qv6nSRhfV_M [4] https://meetings.opendev.org/meetings/releaseteam/2023/releaseteam.2023-11-… [5] https://meetings.opendev.org/meetings/tc/2023/tc.2023-11-14-18.00.log.html#… [6] https://etherpad.opendev.org/p/early-caracal-unmaintained-transition [7] https://review.opendev.org/c/openstack/project-team-guide/+/897505 [8] https://review.opendev.org/c/openstack/governance/+/900940

1 0

Discuss i18n IRC Meeting date
by Seongsoo Cho 15 Nov '23

15 Nov '23

Hi i18n Team. It's time to update our regular meeting date. This is the current meeting date in the doc, but actually, there are no meeting. [1] Every odd week: 16:00 UTC, Thursday Every even week: 07:00 UTC, Thursday So I want to set a new meeting date. For now, I'd like to have a monthly IRC meeting. Please let me know what days and times work best for you. Survey form: https://forms.gle/SZUFmwJS6QTs4akNA Best Regards Seongsoo [1] https://docs.openstack.org/i18n/latest/i18n_team_meeting.html -- Seongsoo Cho OpenStack Korea User Group / Community Leader IRC #seongsoocho

1 0

[ptls][PTG] OpenInfra Live: PTG Recap
by Kristin Barrientos 15 Nov '23

15 Nov '23

Hi Everyone, I wanted to reach out to see if any PTLs were interested in providing their highlights from last month’s PTG in an OpenInfra Live[1] episode on Thursday, December 7 at 1500 UTC. Ideally, we would like to have 4-6 projects represented (OpenStack, Kata, and/or StarlingX). A previous example of a PTG recap episode can be found here[2]. Please let me know if you’re interested and I can provide the next steps. If you would like to provide an update but that time doesn’t work for you, please share a recording with me and I can get it added. Thanks, Kristin Barrientos Marketing Coordinator OpenInfra Foundation [1] openinfra.dev/live [2] https://www.youtube.com/watch?v=yIt4dJvTQVg&t=231s

7 11

[swift]: Swiftstack Zone/DC decommission
by Muralikrishna Gutha 15 Nov '23

15 Nov '23

Hello Team, We currently utilize SwiftStack Object Storage to meet our object storage requirements, and our cluster has a Primary Zone/Secondary Zone topology. Recently, we attempted to remove/disable the Secondary Zone. However, upon doing so, we observed a concerning trend: the storage utilization in the Primary Zone rapidly increased, reaching approximately 90%. This surge was particularly notable due to the use of the 'tworeplicaperregion' policy. In an attempt to address this, we brought the Secondary Zone nodes back online, expecting Swift to redistribute the data back to these nodes and alleviate the storage strain on the Primary Zone. Despite reintegrating the Secondary Zone nodes into the cluster, we continue to witness a persistent rise in storage utilization within the Primary Zone. Interestingly, two out of the three nodes in the Primary Zone seem to bear the brunt of the data and tokens, while the third node is not receiving a proportional distribution of data. At this juncture, we are seeking guidance on potential configurations or adjustments, such as specific knobs, that could expedite the rebalance process. Our objective is to efficiently distribute the data across nodes, particularly in the Primary Zone, and optimize the overall storage utilization in our SwiftStack Object Storage cluster. Any insights or recommendations on tuning parameters for a swifter rebalance would be highly appreciated. Thanks, Murali -- This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this on behalf of the addressee you must not use, copy, disclose or take action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply email and delete this message. Thank you.

3 7

[tc] Next TC Meeting will be Nov 28 (2023-11-21 meeting cancelled)
by Jay Faulkner 14 Nov '23

14 Nov '23

Hi all, The Technical Committee will not be meeting next week. The meeting was cancelled due to American Thanksgiving. Our next meeting will be November 28, 2023. Thanks, Jay Faulkner OpenStack TC Chair

1 0

Implementation review day will be Nov 15
by Sylvain Bauza 14 Nov '23

14 Nov '23

Hey folks, We just agreed during today's meeting on having our first implementation review day this week. In order to make this day efficient, I proposed an etherpad for tracking our efforts https://etherpad.opendev.org/p/nova-caracal-status Shall you want the nova community to look at your changes, you should please add them into the etherpad in the very last section ('proposed bugfixes') and then me and a few other cores will curate that list. Tomorrow, we'll scrub the list of approved blueprints's patches and the bugfixes' ones that got approved as a review priority and we'll iterate over them. Please try to look at your Gerrit emails, you could get comments ;-) Thanks, -Sylvain

1 1