Merge branch 'main' into feat/v1_29

# Conflicts:
#	terraform/files/bin/openstack-kube-versions.inc

.ansible-lint

@@ -5,6 +5,5 @@ skip_list:
 # Roles and modules imported from https://opendev.org/zuul/zuul-jobs
 mock_roles:
   - ensure-pip
-  - ensure-terraform
 mock_modules:
   - zuul_return

.github/workflows/check-terraform-syntax.yml → .github/workflows/check-opentofu-syntax.yml

@@ -1,18 +1,18 @@
 ---
-name: Check terraform syntax
+name: Check opentofu syntax
 
 "on":
   push:
     paths:
       - 'terraform/**'
-      - '.github/workflows/check-terraform-syntax.yml'
+      - '.github/workflows/check-opentofu-syntax.yml'
   pull_request:
     paths:
       - 'terraform/**'
-      - '.github/workflows/check-terraform.yml'
+      - '.github/workflows/check-opentofu-syntax.yml'
 
 jobs:
-  check-terraform-syntax:
+  check-opentofu-syntax:
     runs-on: ubuntu-latest
 
     steps:
@@ -24,18 +24,18 @@ jobs:
       - name: create credentials
         run: cp secure.yaml.sample secure.yaml
         working-directory: ./terraform
-      - name: Setup terraform
-        uses: hashicorp/setup-terraform@v2
+      - name: Setup OpenTofu
+        uses: opentofu/setup-opentofu@v1
         with:
-          terraform_version: 1.4.6  # renovate: datasource=github-releases depName=hashicorp/terraform
-      - name: Terraform init
-        run: terraform init
+          tofu_version: 1.6.0  # renovate: datasource=github-releases depName=opentofu/opentofu
+      - name: Tofu init
+        run: tofu init
         working-directory: ./terraform
-      - name: Terraform validate
-        run: terraform validate
+      - name: Tofu validate
+        run: tofu validate
         working-directory: ./terraform
         env:
           ENVIRONMENT: gx-betacloud
-      - name: Terraform format
-        run: terraform fmt -check
+      - name: Tofu format
+        run: tofu fmt -check
         working-directory: ./terraform

doc/Upgrade-Guide.md

@@ -10,8 +10,9 @@ state: Draft (v0.7)
 This document explains the steps to upgrade the SCS Kubernetes cluster-API
 based cluster management solution as follows:
 - from the R2 (2022-03) to the R3 (2022-09) state
-- from the R3 (2022-09) to the R4 state
-- from the R4 (2023-09) to the R5 state
+- from the R3 (2022-09) to the R4 (2023-03) state
+- from the R4 (2023-03) to the R5 (2022-09) state
+
 The document explains how the management cluster and the workload clusters can be
 upgraded without disruption. It is highly recommended to do a step-by-step upgrade
 across major releases i.e. upgrade from R2 to R3 and then to R4 in the case of
@@ -23,22 +24,22 @@ take, and it is advisable that cluster operators get some experience with
 this kind of cluster management before applying this to customer clusters
 that carry important workloads.
 
-Note that while the detailed steps are tested and targeted to a R2 -> R3 move,
+Note that while the detailed steps are tested and targeted to an R2 -> R3 move,
 R3 -> R4 move or R4 -> R5 move, many of the steps are a generic approach that will apply also for other
 upgrades, so expect a lot of similar steps when moving beyond R5.
 
-Upgrades from cluster management prior to R2 is difficult; many changes before
+Upgrades from cluster management prior to R2 are difficult; many changes before
 R2 assumed that you would redeploy the management cluster. Redeploying the
 management cluster can of course always be done, but it's typically disruptive
 to your workload clusters, unless you move your cluster management state into
 a new management cluster with `clusterctl move`.
 
 ## Management host (cluster) vs. Workload clusters
 
-When you initially deployed the SCS k8s-cluster-api-provider, you create a
+When you initially deployed the SCS k8s-cluster-api-provider, you created a
 VM with a [kind](https://kind.sigs.k8s.io/) cluster inside and a number of
 templates, scripts and binaries that are then used to do the cluster management.
-This is your management host (or more precisely you single-host management
+This is your management host (or more precisely your single-host management
 cluster). Currently, all cluster management including upgrading etc. is done
 by connecting to this host via ssh and performing commands there. (You don't
 need root privileges to do cluster management there, the normal ubuntu user
@@ -134,8 +135,11 @@ You can now apply the upgrade by executing the following command:
 clusterctl upgrade apply --contract v1beta1
 ```
 
-You can then upgrade the components. You can do them one-by-one or simply do
-`clusterctl upgrade apply --contract v1beta1`
+You can then upgrade the components. You can do them one-by-one, e.g.:
+```bash
+clusterctl upgrade apply --infrastructure capo-system/openstack:v0.7.3 --core capi-system/cluster-api:v1.5.1 -b capi-kubeadm-bootstrap-system/kubeadm:v1.5.1 -c capi-kubeadm-control-plane-system/kubeadm:v1.5.1
+```
+Or simply do `clusterctl upgrade apply --contract v1beta1`.
 
 #### New templates
 
@@ -151,7 +155,7 @@ on the cluster unless you have changed its configuration by tweaking
 `cluster-template.yaml` (which you almost never do!) or `clusterctl.yaml`
 (which you do often).
 
-The other template file that changed -- however, some terraform logic is used to
+The other template file that changed -- however, some opentofu logic is used to
 prefill it with values. So you can't copy it from git.
 
 ##### R2 to R3
@@ -337,11 +341,11 @@ If you decide to migrate your existing Kubernetes cluster from R4 to R5 be aware
 
 Follow the below steps if you want to migrate an existing cluster from R4 to R5:
 1. Access your management node
-2. Checkout R5 tag
+2. Checkout R5 branch
    ```bash
    cd k8s-cluster-api-provider
    git pull
-   git checkout tags/v6.0.0
+   git checkout maintained/v6.x
    ```
 3. Backup an existing cluster configuration files (recommended)
    ```bash
@@ -357,7 +361,7 @@ Follow the below steps if you want to migrate an existing cluster from R4 to R5:
    and are not directly mentioned in the cluster configuration files, but they are hardcoded
    in R5 scripts (e.g. ingress nginx controller, metrics server). Hence, read carefully the
    R5 release notes too. Also see that Kubernetes version was not updated, and it is still v1.25.6.
-6. Update an existing cluster (expect Kubernetes version)
+6. Update an existing cluster (except Kubernetes version)
    ```bash
    create_cluster.sh <CLUSTER_NAME>
    ```
@@ -380,7 +384,7 @@ Follow the below steps if you want to migrate an existing cluster from R4 to R5:
 10. Bump Kubernetes version to R5 v1.27.5 and increase the generation counter for node and control plane nodes
    ```bash
    sed -i 's/^KUBERNETES_VERSION: v1.26.8/KUBERNETES_VERSION: v1.27.5/' <CLUSTER_NAME>/clusterctl.yaml
-   sed -i 's/^OPENSTACK_IMAGE_NAME: ubuntu-capi-image-v1.26.8 /OPENSTACK_IMAGE_NAME: ubuntu-capi-image-v1.27.5/' <CLUSTER_NAME>/clusterctl.yaml
+   sed -i 's/^OPENSTACK_IMAGE_NAME: ubuntu-capi-image-v1.26.8/OPENSTACK_IMAGE_NAME: ubuntu-capi-image-v1.27.5/' <CLUSTER_NAME>/clusterctl.yaml
    sed -r 's/(^CONTROL_PLANE_MACHINE_GEN: genc)([0-9][0-9])/printf "\1%02d" $((\2+1))/ge' -i <CLUSTER_NAME>/clusterctl.yaml
    sed -r 's/(^WORKER_MACHINE_GEN: genw)([0-9][0-9])/printf "\1%02d" $((\2+1))/ge' -i <CLUSTER_NAME>/clusterctl.yaml
    ```
@@ -395,7 +399,7 @@ OCCM, CNI (calico/cilium), CSI
 
 ### New versions for optional components
 
-nginx, metrics (nothing to do), cert-manager, flux
+nginx, metrics server, cert-manager, flux
 
 ### etcd leader changes
 

doc/application-credentials.md

@@ -1,6 +1,6 @@
 # Application Credentials
 
-The terraform creates an [application credential](https://docs.openstack.org/keystone/wallaby/user/application_credentials.html) that it passes into the created VM. This one is then used to authenticate the cluster API provider against the OpenStack API to allow it to create resources needed for the k8s cluster.
+OpenTofu creates an [application credential](https://docs.openstack.org/keystone/wallaby/user/application_credentials.html) that it passes into the created VM. This one is then used to authenticate the cluster API provider against the OpenStack API to allow it to create resources needed for the k8s cluster.
 
 The AppCredential has a few advantages:
 

doc/configuration.md

@@ -21,8 +21,8 @@ Parameters controlling the Cluster-API management server (capi management server
 | `kind_flavor`            |                 | SCS        | `SCS-2V-4`        | Flavor to be used for the k8s capi mgmt server                                                             |
 | `image`                  |                 | SCS        | `Ubuntu 22.04`    | Image for the capi mgmt server. Use `Ubuntu 22.04` or `Debian 12`. Check also the `ssh_username` parameter |
 | `ssh_username`           |                 | SCS        | `ubuntu`          | Name of the default user for the `image`                                                                   |
-| `clusterapi_version`     |                 | SCS        | `1.5.3` <!-- renovate: datasource=github-releases depName=kubernetes-sigs/cluster-api -->          | Version of the cluster-API incl. `clusterctl`                                                              |
-| `capi_openstack_version` |                 | SCS        | `0.8.0` <!-- renovate: datasource=github-releases depName=kubernetes-sigs/cluster-api-provider-openstack -->         | Version of the cluster-api-provider-openstack (needs to fit the CAPI version)                              |
+| `clusterapi_version`     |                 | SCS        | `1.6.1` <!-- renovate: datasource=github-releases depName=kubernetes-sigs/cluster-api -->          | Version of the cluster-API incl. `clusterctl`                                                              |
+| `capi_openstack_version` |                 | SCS        | `0.9.0` <!-- renovate: datasource=github-releases depName=kubernetes-sigs/cluster-api-provider-openstack -->         | Version of the cluster-api-provider-openstack (needs to fit the CAPI version)                              |
 | `cilium_binaries`        |                 | SCS        | `v0.15.7;v0.12.0` | Versions of the cilium and hubble CLI in the vA.B.C;vX.Y.Z format                                          |
 | `restrict_mgmt_server` |                                 | SCS        | `["0.0.0.0/0"]`                      | Allows restricting access to the management server by the given list of CIDRs. Empty value (default) means public.           |
 | `mgmt_cidr`              |                 | SCS        | `10.0.0.0/24` | IPv4 address range (CIDR notation) for management cluster                                          |
@@ -57,7 +57,6 @@ Parameters controlling the cluster creation:
 | ``                               | `OPENSTACK_IMAGE_NAME`                          | capo       | `ubuntu-capi-image-${KUBERNETES_VERION}`                 | Image name for k8s controller and worker nodes. Ubuntu 22.04 image is used for k8s versions >= 1.27.3, 1.26.6, 1.25.11, Ubuntu 20.04 otherwise.                                                            |
 | `kube_image_raw`                 | `OPENSTACK_IMAGE_RAW`                           | SCS        | `true`                                                   | Register images in raw format (instead of qcow2), good for ceph COW                                                                                                                                        |
 | `image_registration_extra_flags` | `OPENSTACK_IMAGE_REGISTATION_EXTRA_FLAGS`       | SCS        | `""`                                                     | Extra flags passed during image registration                                                                                                                                                               |
-| ``                               | `OPENSTACK_CONTROL_PLANE_IP`                    | capo       | `127.0.0.1`                                              | Use localhost to talk to capi cluster (don't change this!)                                                                                                                                                 |
 | ``                               | `OPENSTACK_SSH_KEY_NAME`                        | capo       | `${prefix}-keypair`                                      | SSH key name generated and used to connect to workload cluster nodes                                                                                                                                       |
 | `controller_flavor`              | `OPENSTACK_CONTROL_PLANE_MACHINE_FLAVOR`        | capo       | `SCS-2V-4-20s`                                           | Flavor to be used for control plane nodes                                                                                                                                                                  |
 | `worker_flavor`                  | `OPENSTACK_NODE_MACHINE_FLAVOR`                 | capo       | `SCS-2V-4-20s`                                           | Flavor to be used for worker nodes                                                                                                                                                                         |

doc/continuous-integration.md

@@ -80,7 +80,7 @@ This section describes Zuul jobs defined within the k8s-cluster-api-provider pro
     availability in Zuul worker node. Parent job also defines a Zuul semaphore `semaphore-openstack-access`,
     that ensures that only one `openstack-access-base` job (or its children) can run at a time
   - See a high level `k8s-cluster-api-provider-e2e-conformance` job steps:
-    - Pre-run playbook `dependencies.yaml` installs project prerequisites, e.g. terraform, yq, etc. 
+    - Pre-run playbook `dependencies.yaml` installs project prerequisites, e.g. opentofu, yq, etc.
     - Main playbook `e2e.yaml` spawns a k8s cluster, runs sonobuoy conformance test, and cleans created infrastructure, all by k8s-cluster-api-provider scripts
     - Cleanup-run playbook `cleanup.yaml` runs `ospurge`, cleanup created application credentials and keypair to ensure that multiple e2e runs do not interfere
 
@@ -90,7 +90,7 @@ This section describes Zuul jobs defined within the k8s-cluster-api-provider pro
     availability in Zuul worker node. Parent job also defines a Zuul semaphore `semaphore-openstack-access`,
     that ensures that only one `openstack-access-base` job (or its children) can run at a time
   - See a high level `k8s-cluster-api-provider-e2e-quick` job steps:
-    - Pre-run playbook `dependencies.yaml` installs project prerequisites, e.g. terraform, yq, etc. 
+    - Pre-run playbook `dependencies.yaml` installs project prerequisites, e.g. opentofu, yq, etc.
     - Main playbook `e2e.yaml` spawns a k8s cluster, runs sonobuoy quick test, and cleans created infrastructure, all by k8s-cluster-api-provider scripts
     - Cleanup-run playbook `cleanup.yaml` runs `ospurge`, cleanup created application credentials and keypair to ensure that multiple e2e runs do not interfere
 

doc/make-reference.md

@@ -86,13 +86,13 @@ This will deploy the [cluster-stack-operator](https://github.com/SovereignCloudS
 ### Make clean
 
 ``make clean`` does ssh to the capi management server to clean up the created clusters prior
-to terraform cleaning up the resources it has created. This is sometimes insufficient to clean up
+to opentofu cleaning up the resources it has created. This is sometimes insufficient to clean up
 unfortunately, some error in the deployment may result in resources left around.
 
 ### Make fullclean
 
 ``make fullclean`` uses a custom script `cleanup/cleanup.sh` (using the openstack CLI) to clean up
-everything while trying to not hit any resources not created by the CAPI or terraform for
+everything while trying to not hit any resources not created by the CAPI or opentofu for
 clusters from this management host.
 It is the recommended way for doing cleanups if ``make clean`` fails. Watch out for leftover
 floating IP addresses and persistent volumes, as these can not be easily traced back to the
@@ -105,7 +105,7 @@ case we don't need the force options.
 
 You can purge the whole project via ``make purge``. Be careful with that command as it will purge
 *all resources in the OpenStack project* even those that have not been created through this
-Terraform script or the Cluster API.
+OpenTofu script or the Cluster API.
 It requires the [``ospurge``](https://opendev.org/x/ospurge) tool.
 Install it with ``python3 -m pip install git+https://git.openstack.org/openstack/ospurge``.
 
@@ -145,52 +145,52 @@ This will run tests of the configuration on testcluster using sonobuoy of the st
 
 This will run tests of the configuration on testcluster using sonobuoy of the CSI.
 
-## Terraform commands
+## OpenTofu commands
 
 ### make init
 
 ``make init``
 
-This will initialize terraform. It will download the required providers and modules.
+This will initialize opentofu. It will download the required providers and modules.
 It will also select or create a new workspace for you. The workspace name is the same as the
 ``ENVIROMENT`` variable.
 
 ### make attach
 
 ``make attach RESOURCE=<resource-id> PARAMS=...``
 
-This will attach a resource to the terraform state. This is useful if you have created a resource outside of terraform
-and want to manage it with terraform.
+This will attach a resource to the opentofu state. This is useful if you have created a resource outside of opentofu
+and want to manage it with opentofu.
 
 ### make detach
 
 ``make detach RESOURCE=<resource-id> PARAMS=...``
 
-This will detach a resource from the terraform state. This is useful if you have changed a resource outside of terraform
-or you no longer want to manage it with terraform.
+This will detach a resource from the opentofu state. This is useful if you have changed a resource outside of opentofu
+or you no longer want to manage it with opentofu.
 
 ### make state-push
 
 ``make state-push``
 
-This will push the terraform state to specified storage if set. This is useful if you don't want to store the state
+This will push the opentofu state to specified storage if set. This is useful if you don't want to store the state
 locally.
 
 ### make dry-run
 
 ``make dry-run``
 
-This will run a dry-run of the terraform apply command. This is useful if you want to see what terraform will do before
+This will run a dry-run of the opentofu apply command. This is useful if you want to see what opentofu will do before
 actually doing it.
 
 ### make show
 
 ``make show``
 
-This will show the terraform state. This is useful if you want to see what terraform is managing.
+This will show the opentofu state. This is useful if you want to see what opentofu is managing.
 
 ### make list
 
 ``make list``
 
-This will list all the resources managed by terraform. This is useful if you want to see what terraform is managing.
+This will list all the resources managed by opentofu. This is useful if you want to see what opentofu is managing.