Merge branch 'stackhpc/2024.1' into aarch64-image-build

Author: m-bull

.github/workflows/stackhpc-update-kolla.yml

@@ -0,0 +1,23 @@
+name: Update Kolla versions
+
+on:
+  # Allow manual executions
+  workflow_dispatch:
+  # Run nightly
+  schedule:
+    - cron: '0 0 * * *'
+
+jobs:
+  update-from-branch:
+    name: Update dependencies
+    strategy:
+      matrix:
+        include:
+          - version: stackhpc/2023.1
+          - version: stackhpc/2024.1
+    uses: ./.github/workflows/update-dependencies.yml
+    with:
+      openstack_version: ${{ matrix.version }}
+    permissions:
+      contents: write
+      pull-requests: write

.github/workflows/update-dependencies.yml

@@ -1,11 +1,12 @@
 name: Update dependencies
 
 on:
-  # Allow manual executions
-  workflow_dispatch:
-  # Run nightly
-  schedule:
-    - cron: '0 0 * * *'
+  workflow_call:
+    inputs:
+      openstack_version:
+        description: OpenStack version
+        type: string
+        required: true
 
 jobs:
   propose_github_release_updates:
@@ -38,20 +39,14 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v4
         with:
+          ref: ${{ inputs.openstack_version }}
           path: ${{ github.workspace }}/src/kayobe-config
 
-      - name: Determine OpenStack release
-        id: openstack_release
-        run: |
-          BRANCH=$(awk -F'=' '/defaultbranch/ {print $2}' .gitreview)
-          echo "openstack_release=${BRANCH}" | sed -E "s,(stable|unmaintained)/,," >> $GITHUB_OUTPUT
-        working-directory: ${{ github.workspace }}/src/kayobe-config
-
       - name: Checkout the dependency repo
         uses: actions/checkout@v4
         with:
           repository: ${{ matrix.repository }}
-          ref: stackhpc/${{ steps.openstack_release.outputs.openstack_release }}
+          ref: ${{ inputs.openstack_version }}
           fetch-tags: true
           path: ${{ github.workspace }}/src/${{ matrix.key }}
 
@@ -78,10 +73,10 @@ jobs:
           path: ${{ github.workspace }}/src/kayobe-config
           commit-message: >-
             Bump ${{ matrix.key }} to ${{ steps.latest_tag.outputs.latest_tag }}
-          branch: update-dependency/${{ matrix.key }}
+          branch: update-dependency/${{ matrix.key }}/${{ inputs.openstack_version }}
           delete-branch: true
           title: >-
-            Bump ${{ matrix.key }} to ${{ steps.latest_tag.outputs.latest_tag }}
+            Bump ${{ inputs.openstack_version }} ${{ matrix.key }} to ${{ steps.latest_tag.outputs.latest_tag }}
           body: >
-            This PR was created automatically to update
+            This PR was created automatically to update ${{ inputs.openstack_version }}
             ${{ matrix.key }} to ${{ steps.latest_tag.outputs.latest_tag }}.

doc/source/configuration/cephadm.rst

@@ -1,6 +1,8 @@
-====
-Ceph
-====
+.. _cephadm-kayobe:
+
+================
+Cephadm & Kayobe
+================
 
 This section describes how to use the Cephadm integration included in StackHPC
 Kayobe configuration to deploy Ceph.
@@ -204,8 +206,8 @@ Pools
 ~~~~~
 
 The following example pools should be sufficient to work with the
-default `external Ceph
-configuration <https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-ceph-guide.html>`__
+default :kolla-ansible-doc:`external Ceph
+configuration <reference/storage/external-ceph-guide.html>`
 for Cinder, Cinder backup, Glance, and Nova in Kolla Ansible.
 
 .. code:: yaml
@@ -232,8 +234,8 @@ Keys
 ~~~~
 
 The following example keys should be sufficient to work with the default
-`external Ceph
-configuration <https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-ceph-guide.html>`__
+:kolla-ansible-doc:`external Ceph
+configuration <reference/storage/external-ceph-guide.html>`
 for Cinder, Cinder backup, Glance, and Nova in Kolla Ansible.
 
 .. code:: yaml
@@ -349,7 +351,7 @@ RADOS Gateways
 
 RADOS Gateway integration is described in the :kolla-ansible-doc:`Kolla Ansible
 documentation
-<https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-ceph-guide.html#radosgw>`.
+<reference/storage/external-ceph-guide.html#radosgw>`.
 
 RADOS Gateways (RGWs) are defined with the following:
 

doc/source/configuration/ci-cd.rst

@@ -57,26 +57,26 @@ Runner Deployment
     Ideally an Infra VM could be used here or failing that the control host.
     Wherever it is deployed the host will need access to the :code:`admin_network`, :code:`public_network` and the :code:`pulp registry` on the seed.
 
-2. Edit the environment's :code:`${KAYOBE_CONFIG_PATH}/environments/${KAYOBE_ENVIRONMENT}/inventory/groups` to add the predefined :code:`github-runners` group to :code:`infra-vms`
+2. Edit the environment's :code:`$KAYOBE_CONFIG_PATH/environments/$KAYOBE_ENVIRONMENT/inventory/groups` to add the predefined :code:`github-runners` group to :code:`infra-vms`
 
 .. code-block:: ini
 
     [infra-vms:children]
     github-runners
 
-3. Edit the environment's :code:`${KAYOBE_CONFIG_PATH}/environments/${KAYOBE_ENVIRONMENT}/inventory/hosts` to define the host(s) that will host the runners.
+3. Edit the environment's :code:`$KAYOBE_CONFIG_PATH/environments/$KAYOBE_ENVIRONMENT/inventory/hosts` to define the host(s) that will host the runners.
 
 .. code-block:: ini
 
     [github-runners]
     prod-runner-01
 
-4. Provide all the relevant Kayobe :code:`group_vars` for :code:`github-runners` under :code:`${KAYOBE_CONFIG_PATH}/environments/${KAYOBE_ENVIRONMENT}/inventory/group_vars/github-runners`
+4. Provide all the relevant Kayobe :code:`group_vars` for :code:`github-runners` under :code:`$KAYOBE_CONFIG_PATH/environments/$KAYOBE_ENVIRONMENT/inventory/group_vars/github-runners`
     * `infra-vms` ensuring all required `infra_vm_extra_network_interfaces` are defined
     * `network-interfaces`
     * `python-interpreter.yml` ensuring that `ansible_python_interpreter: /usr/bin/python3` has been set
 
-5. Edit the ``${KAYOBE_CONFIG_PATH}/inventory/group_vars/github-runners/runners.yml`` file which will contain the variables required to deploy a series of runners.
+5. Edit the ``$KAYOBE_CONFIG_PATH/inventory/group_vars/github-runners/runners.yml`` file which will contain the variables required to deploy a series of runners.
    Below is a core set of variables that will require consideration and modification for successful deployment of the runners.
    The number of runners deployed can be configured by removing and extending the dict :code:`github-runners`.
    As for how many runners present three is suitable number as this would prevent situations where long running jobs could halt progress other tasks whilst waiting for a free runner.
@@ -118,9 +118,9 @@ Runner Deployment
     The repository permissions for a fine-grained personal access token should be; :code:`Actions: R/W, Administration: R/W, Metadata: R`
     Once the key has been obtained, add it to :code:`secrets.yml` under :code:`secrets_github_access_token`
 
-7. If the host is an actual Infra VM then please refer to upstream `Infrastructure VMs <https://docs.openstack.org/kayobe/latest/configuration/reference/infra-vms.html>`__ documentation for additional configuration and steps.
+7. If the host is an actual Infra VM then please refer to upstream :kayobe-doc:`Infrastructure VMs <configuration/reference/infra-vms.html>` documentation for additional configuration and steps.
 
-8. Run :code:`kayobe playbook run ${KAYOBE_CONFIG_PATH}/ansible/deploy-github-runner.yml`
+8. Run :code:`kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/deploy-github-runner.yml`
 
 9. Check runners have registered properly by visiting the repository's :code:`Action` tab -> :code:`Runners` -> :code:`Self-hosted runners`
 
@@ -130,9 +130,9 @@ Runner Deployment
 Workflow Deployment
 -------------------
 
-1. Edit :code:`${KAYOBE_CONFIG_PATH}/inventory/group_vars/github-writer/writer.yml` in the base configuration making the appropriate changes to your deployments specific needs. See documentation for `stackhpc.kayobe_workflows.github <https://github.com/stackhpc/ansible-collection-kayobe-workflows/tree/main/roles/github>`__.
+1. Edit :code:`$KAYOBE_CONFIG_PATH/inventory/group_vars/github-writer/writer.yml` in the base configuration making the appropriate changes to your deployments specific needs. See documentation for `stackhpc.kayobe_workflows.github <https://github.com/stackhpc/ansible-collection-kayobe-workflows/tree/main/roles/github>`__.
 
-2. Run :code:`kayobe playbook run ${KAYOBE_CONFIG_PATH}/ansible/write-github-workflows.yml`
+2. Run :code:`kayobe playbook run $KAYOBE_CONFIG_PATH/ansible/write-github-workflows.yml`
 
 3. Add all required secrets and variables to repository either via the GitHub UI or GitHub CLI (may require repository owner)
 

doc/source/configuration/cloudkitty.rst

@@ -8,8 +8,8 @@ Configuring in kayobe-config
 By default, CloudKitty uses Gnocchi and Ceilometer as the collector and fetcher
 backends. Unless the system has a specific reason not to, we recommend instead
 using Prometheus as the backend for both. The following instructions explain
-how to do this. Also, see the `Kolla Ansible docs on CloudKitty
-<https://docs.openstack.org/kolla-ansible/latest/reference/rating/cloudkitty-guide.html>`__
+how to do this. Also, see the :kolla-ansible-doc:`Kolla Ansible docs on CloudKitty
+<reference/rating/cloudkitty-guide.html>`
 for more details.
 
 Enable CloudKitty and disable InfluxDB, as we are using OpenSearch as the

doc/source/configuration/lvm.rst

@@ -93,6 +93,6 @@ hosts:
 
 .. code-block:: console
 
-   mkdir -p ${KAYOBE_CONFIG_PATH}/hooks/overcloud-host-configure/pre.d
-   cd ${KAYOBE_CONFIG_PATH}/hooks/overcloud-host-configure/pre.d
+   mkdir -p $KAYOBE_CONFIG_PATH/hooks/overcloud-host-configure/pre.d
+   cd $KAYOBE_CONFIG_PATH/hooks/overcloud-host-configure/pre.d
    ln -s ../../../ansible/growroot.yml 30-growroot.yml

doc/source/configuration/monitoring.rst

@@ -2,6 +2,8 @@
 Monitoring
 ==========
 
+.. _monitoring-service-configuration:
+
 Monitoring Configuration
 ========================
 

doc/source/configuration/release-train.rst

@@ -1,4 +1,4 @@
-.. _stackhpc_release_train:
+.. _stackhpc-release-train:
 
 ======================
 StackHPC Release Train

doc/source/configuration/vault.rst

@@ -1,3 +1,5 @@
+.. _hashicorp-vault:
+
 ================================
 Hashicorp Vault for internal PKI
 ================================
@@ -168,6 +170,9 @@ Certificates generation
 Create the external TLS certificates (testing only)
 ---------------------------------------------------
 
+This method should only be used for testing. For external TLS on production systems,
+See `Installing External TLS Certificates <installing-external-tls-certificates>`__.
+
 Typically external API TLS certificates should be generated by a organisation's trusted internal or third-party CA.
 For test and development purposes it is possible to use Vault as a CA for the external API.