Hi Thamanna,

> Since OpenStack 2023.1 is not explicitly listed as a supported version in OpenStack-Helm
It is not only explicitly listed on the Openstack-Helm wiki page, but also it is not officially maintained Openstack release. Please see [1]. So I would definitely recommend using the newer SLURP release.

> As a workaround, I tested with RabbitMQ 3.12, which worked without issues. However, I need to use RabbitMQ 3.11 to align with OpenStack 2023.1.

Openstack is a complicated system with many moving parts, and I wouldn't consider any recommendations as something carved in granite. Rabbitmq minor updates are backward compatible so I would say it is safe to use 3.12 and even 3.13 if it works for you.

> Is OpenStack 2023.1 officially supported with OpenStack-Helm? If not, what is the recommended approach to deploy this version?

No. It is not officially supported. We only test all chart changes with the currently maintained Openstack releases. See [1]. As a result, recent changes might be incompatible with older Openstack releases but there is a good chance that charts still work with 2023.1 (we just don't test them with 2023.1).

> Are there any known issues or workarounds for the Keystone image and Alembic revision error?
This error you are referring to is likely because you first tried to deploy 2024.1 and only then you added 2023.1 overrides. As a result you have this migration in the database. So you can try to redeploy the MariaDB and try again.


[1] https://releases.openstack.org/

On Fri, Feb 28, 2025 at 12:33 PM Thamanna Farhath <thamanna.f@zybisys.com> wrote:

Hi Karl Kloppenborg,

I am currently working on setting up OpenStack 2023.1 on a Kubernetes cluster using Rook-Ceph for storage. I am using OpenStack-Helm for deployment and have encountered a few issues during the installation process. 

I have followed the official OpenStack-Helm documentation and deployment guides:

Since OpenStack 2023.1 is not explicitly listed as a supported version in OpenStack-Helm, I have used the latest Helm charts and made necessary overrides to align with OpenStack 2023.1.


  1. Kubernetes Cluster: Running with Rook-Ceph for storage.

  2. OpenStack Version: Targeting 2023.1.

  3. OpenStack-Helm: Using the latest charts but overriding versions to match 2023.1.

Issues Faced:

1. RabbitMQ Version Mismatch:

  • The default RabbitMQ version in OpenStack-Helm is 3.13, but OpenStack 2023.1 supports RabbitMQ 3.11.

  • I overrode the RabbitMQ version to 3.11, but it resulted in the following error:

2025-02-26 09:18:32.188839+00:00 [error] <0.229.0> BOOT FAILED
2025-02-26 09:18:32.188839+00:00 [error] <0.229.0> ===========
2025-02-26 09:18:32.188839+00:00 [error] <0.229.0> Error during startup: {error,
2025-02-26 09:18:32.188839+00:00 [error] <0.229.0>                           {inconsistent_cluster,
2025-02-26 09:18:32.188839+00:00 [error] <0.229.0>                               "Node 'rabbit@rabbitmq-rabbitmq-0.rabbitmq.openstack.svc.cluster.local' thinks it's clustered with node 'rabbit@rabbitmq-rabbitmq-1.rabbitmq.openstack.svc.cluster.local', but 'rabbit@rabbitmq-rabbitmq-1.rabbitmq.openstack.svc.cluster.local' disagrees"}}

  • As a workaround, I tested with RabbitMQ 3.12, which worked without issues. However, I need to use RabbitMQ 3.11 to align with OpenStack 2023.1.

2. Keystone Image Issue:

2025-02-26 04:32:35.873 7 CRITICAL keystone [-] Unhandled error: alembic.util.exc.CommandError: Can't locate revision identified by '47147121'
2025-02-26 04:32:35.873 7 ERROR keystone Traceback (most recent call last):
2025-02-26 04:32:35.873 7 ERROR keystone   File "/var/lib/openstack/lib/python3.10/site-packages/alembic/script/base.py", line 233, in _catch_revision_errors
2025-02-26 04:32:35.873 7 ERROR keystone     yield
2025-02-26 04:32:35.873 7 ERROR keystone   File "/var/lib/openstack/lib/python3.10/site-packages/alembic/script/base.py", line 443, in _upgrade_revs
2025-02-26 04:32:35.873 7 ERROR keystone     for script in reversed(list(revs))
2025-02-26 04:32:35.873 7 ERROR keystone   File "/var/lib/openstack/lib/python3.10/site-packages/alembic/script/revision.py", line 799, in iterate_revisions
2025-02-26 04:32:35.873 7 ERROR keystone     revisions, heads = fn(
2025-02-26 04:32:35.873 7 ERROR keystone   File "/var/lib/openstack/lib/python3.10/site-packages/alembic/script/revision.py", line 1454, in _collect_upgrade_revisions
2025-02-26 04:32:35.873 7 ERROR keystone     current_revisions = self.get_revisions(lower)
2025-02-26 04:32:35.873 7 ERROR keystone   File "/var/lib/openstack/lib/python3.10/site-packages/alembic/script/revision.py", line 527, in get_revisions
2025-02-26 04:32:35.873 7 ERROR keystone     return sum([self.get_revisions(id_elem) for id_elem in id_], ())
2025-02-26 04:32:35.873 7 ERROR keystone   File "/var/lib/openstack/lib/python3.10/site-packages/alembic/script/revision.py", line 552, in get_revisions
2025-02-26 04:32:35.873 7 ERROR keystone     return tuple(
2025-02-26 04:32:35.873 7 ERROR keystone   File "/var/lib/openstack/lib/python3.10/site-packages/alembic/script/revision.py", line 553, in <genexpr>
2025-02-26 04:32:35.873 7 ERROR keystone     self._revision_for_ident(rev_id, branch_label)
2025-02-26 04:32:35.873 7 ERROR keystone   File "/var/lib/openstack/lib/python3.10/site-packages/alembic/script/revision.py", line 624, in _revision_for_ident
2025-02-26 04:32:35.873 7 ERROR keystone     raise ResolutionError(
2025-02-26 04:32:35.873 7 ERROR keystone alembic.script.revision.ResolutionError: No such revision or branch '47147121'

  • The full error trace is attached above for reference.

Questions:

  1. Is OpenStack 2023.1 officially supported with OpenStack-Helm? If not, what is the recommended approach to deploy this version?

  2. How can I resolve the RabbitMQ version mismatch issue while ensuring compatibility with OpenStack 2023.1?

  3. Are there any known issues or workarounds for the Keystone image and Alembic revision error?

Thank you in advance for your help and support. Please let me know if additional details are required.




---- On Thu, 27 Feb 2025 19:13:50 +0530 Karl Kloppenborg <kkloppenborg@resetdata.com.au> wrote ---

Hi Thamanna,

Thanks for your email, can you please provide us with information on the issues you encountered? Any errors that came up?

Thanks,
Karl.


Karl Kloppenborg

Chief Technology Officer


m: +61 437 239 565
 resetdata.com

reset.png

ResetData supports Mandatory Client Related Financial Disclosures – Scope 3 Emissions Reporting
For more information on the phasing of these requirements for business please visit;  
https://treasury.gov.au/sites/default/files/2024-01/c2024-466491-policy-state.pdf

This email transmission is intended only for the addressee / person responsible for delivery of the message to such person and may contain confidential or privileged information. Confidentiality and legal privilege are not waived or lost by reason of mistaken delivery to you, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. Whilst this email has been checked for viruses, the sender does not warrant that any attachments are free from viruses or other defects. You assume all liability for any loss, damage or other consequences which may arise from opening or using the attachments. If you received this e-mail in error please delete it and any attachments and kindly notify us by immediately sending an email to contact@resetdata.com.au

From: Thamanna Farhath <thamanna.f@zybisys.com>
 Date: Thursday, 27 February 2025 at 10:23 pm
 To: openstack-discuss <openstack-discuss@lists.openstack.org>
 Subject: Assistance Required: OpenStack Helm Deployment (Version 2023.1) Compatibility Issues


Hello OpenStack Community,

I hope you are doing well.

I am currently deploying OpenStack on top of a Kubernetes cluster using OpenStack Helm and aiming to install the 2023.1 (Antelope) version. However, I am facing difficulties in installing this specific version via Helm charts. Despite my attempts, I have not been able to successfully deploy the required OpenStack services for this release.

Additionally, I am ensuring that the dependent services, such as RabbitMQ, align with the compatibility requirements of OpenStack 2023.1. As per the OpenStack documentation, RabbitMQ 3.11 is the recommended version, but I encountered issues while deploying it. Instead, I found that RabbitMQ 3.12 works without any issues.

I would like to know:

  1. Is there a way to install OpenStack 2023.1 properly using Helm charts, or should I consider using a newer OpenStack version?
  2. Will using RabbitMQ 3.12 instead of 3.11 cause any potential issues with OpenStack services, or is it safe to proceed with this version?
  3. Are there any known workarounds or recommendations for deploying OpenStack 2023.1 using Helm?

I would appreciate any guidance, best practices, or documentation references that could help resolve these challenges.

Looking forward to your valuable insights.




Disclaimer :  The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender.

 

E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."






Disclaimer :  The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender.

 

E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."




--
Best regards,
Kozhukalov Vladimir