Merge pull request #773 from stackhpc/upstream/2025.1-2025-08-19

Synchronise 2025.1 with upstream

Author: priteau

ansible/group_vars/all.yml

@@ -503,7 +503,7 @@ kuryr_port: "23750"
 
 letsencrypt_webserver_port: "8081"
 letsencrypt_managed_certs: "{{ '' if not enable_letsencrypt | bool else ('internal' if letsencrypt_internal_cert_server != '' and kolla_same_external_internal_vip | bool else ('internal,external' if letsencrypt_internal_cert_server != '' and letsencrypt_external_cert_server != '' else ('internal' if letsencrypt_internal_cert_server != '' else ('external' if letsencrypt_external_cert_server != '' and not kolla_same_external_internal_vip | bool else '')))) }}"
-letsencrypt_external_cert_server: ""
+letsencrypt_external_cert_server: "https://acme-v02.api.letsencrypt.org/directory"
 letsencrypt_internal_cert_server: ""
 
 magnum_internal_fqdn: "{{ kolla_internal_fqdn }}"

ansible/roles/neutron/templates/neutron-server.json.j2

@@ -1,5 +1,5 @@
 {
-    "command": "neutron-server --config-file /etc/neutron/neutron.conf {% if neutron_plugin_agent in ['openvswitch', 'linuxbridge', 'ovn'] %} --config-file /etc/neutron/plugins/ml2/ml2_conf.ini {% if enable_neutron_vpnaas | bool %}--config-file /etc/neutron/neutron_vpnaas.conf{% endif %}{% elif neutron_plugin_agent in ['vmware_nsxv', 'vmware_nsxv3', 'vmware_nsxp', 'vmware_dvs'] %} --config-file /etc/neutron/plugins/vmware/nsx.ini {% endif %}{% if enable_neutron_fwaas | bool %}--config-file /etc/neutron/fwaas_driver.ini{% endif %}",
+    "command": "neutron-server --config-file /etc/neutron/neutron.conf{% if neutron_plugin_agent in ['openvswitch', 'linuxbridge', 'ovn'] %} --config-file /etc/neutron/plugins/ml2/ml2_conf.ini{% if enable_neutron_vpnaas | bool %} --config-file /etc/neutron/neutron_vpnaas.conf{% endif %}{% elif neutron_plugin_agent in ['vmware_nsxv', 'vmware_nsxv3', 'vmware_nsxp', 'vmware_dvs'] %} --config-file /etc/neutron/plugins/vmware/nsx.ini {% endif %}{% if enable_neutron_fwaas | bool %} --config-file /etc/neutron/fwaas_driver.ini{% endif %}",
     "config_files": [
         {
             "source": "{{ container_config_directory }}/neutron.conf",

doc/source/admin/tls.rst

@@ -316,19 +316,26 @@ to the HAProxy containers using SSH.
   with HAProxy.
 
 You can configure separate ACME servers for internal and external
-certificate requests.
-
-.. code-block:: yaml
-
-  letsencrypt_external_cert_server: "<ACME server URL for external cert>"
-  letsencrypt_internal_cert_server: "<ACME server URL for internal cert>"
-
-.. note::
-
-  The ``letsencrypt_external_cert_server`` has a default value of
-  ``https://acme-v02.api.letsencrypt.org/directory``. Ensure that
-  ``letsencrypt_internal_cert_server`` is reachable from the controller
-  if you configure it for internal certificate requests.
+certificate requests by setting server URL on
+``letsencrypt_internal_cert_server`` and
+``letsencrypt_external_cert_server`` respectively.
+The default is external certificate ACME server set to
+``https://acme-v02.api.letsencrypt.org/directory``.
+
+.. list-table:: Let's Encrypt management
+   :widths: 28 72
+   :header-rows: 1
+
+   * - Desired outcome
+     - Settings
+   * - External only (default)
+     - Enable Let's Encrypt; no further changes.
+   * - External + internal
+     - Set ``letsencrypt_internal_cert_server`` and ensure it is reachable
+       from the controller.
+   * - Internal only
+     - Set ``letsencrypt_external_cert_server: ""`` and set
+       ``letsencrypt_internal_cert_server``.
 
 .. _admin-tls-generating-a-private-ca:
 

doc/source/reference/message-queues/rabbitmq.rst

@@ -110,9 +110,25 @@ The ``+sbwt none +sbwtdcpu none +sbwtdio none`` arguments prevent busy waiting
 of the scheduler, for more details see:
 https://www.rabbitmq.com/runtime.html#busy-waiting.
 
+.. _high-availability:
+
 High Availability
 ~~~~~~~~~~~~~~~~~
 
+.. warning::
+
+   In the Epoxy release of Kolla, the version of RabbitMQ will be updated to
+   4.0. As a result, **all queues must be migrated to a durable type prior to
+   upgrading to Epoxy.** This can be done by setting the following options and
+   then following the migration procedure outlined below.
+
+   .. code-block:: yaml
+
+      om_enable_queue_manager: true
+      om_enable_rabbitmq_quorum_queues: true
+      om_enable_rabbitmq_transient_quorum_queue: true
+      om_enable_rabbitmq_stream_fanout: true
+
 With the release of RabbitMQ 4.0, all queues are highly available as they are
 configured to be quorum queues by default. RabbitMQ also offer queues called
 streams, which can be used to replace "fanout" queues with a more performant
@@ -161,54 +177,52 @@ different type, the follow procedure will be needed.
 
       kolla-ansible deploy --tags <service-tags>
 
-SLURP
-~~~~~
+RabbitMQ Versions
+-----------------
 
-.. note::
+Kolla ships multiple versions of RabbitMQ.
 
-   The version of RabbitMQ did not increase in Dalmatian, so this will not be
-   needed for a skip-level upgrade to Epoxy.
+.. list-table:: Supported RabbitMQ versions
+   :header-rows: 1
 
-RabbitMQ has two major version releases per year but does not support jumping
-two versions in one upgrade. So if you want to perform a skip-level upgrade,
-you must first upgrade RabbitMQ to an intermediary version. To do this, Kolla
-provides multiple RabbitMQ versions in the odd OpenStack releases. To use the
-upgrade from Antelope to Caracal as an example, we start on RabbitMQ version
-3.11. In Antelope, you should upgrade to RabbitMQ version 3.12 with the command
-below. You can then proceed with the usual SLURP upgrade to Caracal (and
-therefore RabbitMQ version 3.13).
+   * - OpenStack Release
+     - Default RabbitMQ version
+     - Additional RabbitMQ version
+   * - 2025.1 Epoxy
+     - 4.0
+     - 4.1
+   * - 2024.1 Caracal/2024.2 Dalmatian
+     - 3.13
+     - 4.1
 
-.. warning::
+Although Kolla-Ansible supports RabbitMQ upgrade when upgrading OpenStack from
+Caracal/Dalmatian to Epoxy, **it is highly recommended to upgrade RabbitMQ to
+4.1 (the latest RabbitMQ supported by Epoxy/Dalmatian/Caracal Kolla-Ansible)
+prior to OpenStack upgrade to Epoxy**
+You can upgrade RabbitMQ to 4.1 with following steps.
 
-   This command should be run from the Antelope release.
+1. Queue migration
 
-   Note that this command is NOT idempotent. See "RabbitMQ versions" below for
-   an alternative approach.
+   See :ref:`high-availability` section above
 
-.. code-block:: console
+2. Set ``rabbitmq_image`` in your configuration ``globals.yml`` to use later version of RabbitMQ
 
-   kolla-ansible rabbitmq-upgrade 3.12
+   .. warning::
 
-RabbitMQ versions
-~~~~~~~~~~~~~~~~~
+      It is recommended to set ``rabbitmq_image`` before running upgrade command to
+      maintain idempotency
 
-Alternatively, you can set ``rabbitmq_image`` in your configuration
-``globals.yml`` for idempotence in deployments. As an example, Kolla ships
-versions 3.11, 3.12 and 3.13 of RabbitMQ in Antelope. By default, Antelope
-Kolla-Ansible will deploy version 3.11. If you wish to deploy a later version,
-you must override the image. if you want to use version 3.12 change
-``rabbitmq_image`` in ``globals.yml`` as follows:
+      If you're upgrading the system from Caracal or Dalmatian and already
+      upgraded RabbitMQ to 4.1, ``rabbitmq_image`` must be overridden as
+      follows to prevent the downgrade of RabbitMQ while upgrading the system to
+      Epoxy.
 
-.. code-block:: yaml
+   .. code-block:: yaml
 
-   rabbitmq_image: "{{ docker_registry ~ '/' if docker_registry else '' }}{{ docker_namespace }}/rabbitmq-3-12"
+      rabbitmq_image: "{{ docker_registry ~ '/' if docker_registry else '' }}{{ docker_namespace }}/rabbitmq-4-1"
 
-You can then upgrade RabbitMQ with the usual command:
+3. Run upgrade command
 
-.. code-block:: console
-
-   kolla-ansible upgrade --tags rabbitmq
+   .. code-block:: console
 
-Note again that RabbitMQ does not support upgrades between more than one major
-version, so if you wish to upgrade to version 3.13 you must first upgrade to
-3.12.
+      kolla-ansible upgrade --tags rabbitmq

doc/source/user/quickstart-development.rst

@@ -102,7 +102,7 @@ Install Kolla-ansible
 
    .. code-block:: console
 
-      pip install ./kolla-ansible
+      pip install -e ./kolla-ansible
 
 #. Create the ``/etc/kolla`` directory.
 
@@ -291,20 +291,19 @@ accordingly.
 
   .. code-block:: console
 
-     cd kolla-ansible/tools
-     ./kolla-ansible bootstrap-servers -i ../../all-in-one
+     kolla-ansible bootstrap-servers -i ../all-in-one
 
 #. Do pre-deployment checks for hosts:
 
   .. code-block:: console
 
-     kolla-ansible prechecks -i ../../all-in-one
+     kolla-ansible prechecks -i ../all-in-one
 
 #. Finally proceed to actual OpenStack deployment:
 
   .. code-block:: console
 
-     kolla-ansible deploy -i ../../all-in-one
+     kolla-ansible deploy -i ../all-in-one
 
 When this playbook finishes, OpenStack should be up, running and functional!
 If error occurs during execution, refer to
@@ -324,8 +323,7 @@ Using OpenStack
 
      .. code-block:: console
 
-        cd kolla-ansible/tools
-        ./kolla-ansible post-deploy
+        kolla-ansible post-deploy
 
    * The file will be generated in /etc/kolla/clouds.yaml, you can use it by
      copying it to /etc/openstack or ~/.config/openstack or setting

releasenotes/notes/set-default-letsencrypt-external-cert-server-d34f9d783082d7d7.yaml

@@ -0,0 +1,13 @@
+---
+fixes:
+  - |
+    Restore the default Let's Encrypt ACME server for external certificates
+    so that enabling ``enable_letsencrypt`` works out of the box again
+    without explicitly setting ``letsencrypt_external_cert_server``. The
+    default is ``https://acme-v02.api.letsencrypt.org/directory``.
+upgrade:
+  - |
+    Deployments using a file-based external certificate and Let's Encrypt for
+    the internal certificate (separate VIPs) default to managing the external
+    certificate with Let's Encrypt. To retain a file-based external
+    certificate, set ``letsencrypt_external_cert_server: ""``.