You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This adds a patch to set the image automatically based on the kubernetes
version. It also removes the requirement to have the CLUSTER_NAME
variable set for the ClusterClass.
Finally, the docs are updated to reflect this and with a few additions.
Signed-off-by: Lennart Jern <[email protected]>
Copy file name to clipboardExpand all lines: docs/book/src/development/development.md
+88-31Lines changed: 88 additions & 31 deletions
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,14 @@
6
6
-[Using your own capi-openstack controller image for testing cluster creation or deletion](#using-your-own-capi-openstack-controller-image-for-testing-cluster-creation-or-deletion)
7
7
-[Building and upload your own capi-openstack controller image](#building-and-upload-your-own-capi-openstack-controller-image)
8
8
-[Using your own capi-openstack controller image](#using-your-own-capi-openstack-controller-image)
9
-
-[Developing with Tilt](#developing-with-tilt)
9
+
-[Testing Cluster Creation using the 'dev-test' ClusterClass with Tilt](#testing-cluster-creation-using-the-dev-test-clusterclass-with-tilt)
10
+
-[Developing with Tilt](#developing-with-tilt)
11
+
-[Apply ClusterClass and create Cluster](#apply-clusterclass-and-create-cluster)
12
+
-[Automatically applying kustomizations with Tilt](#automatically-applying-kustomizations-with-tilt)
13
+
-[Using the 'dev-test' ClusterClass without Tilt](#using-the-dev-test-clusterclass-without-tilt)
14
+
-[Creating a Kind Cluster](#creating-a-kind-cluster)
15
+
-[Secret Configuration](#secret-configuration)
16
+
-[Apply the ClusterClass and create Clusters](#apply-the-clusterclass-and-create-clusters)
-[Support for clouds using SSL](#support-for-clouds-using-ssl)
12
19
-[Support for clouds with multiple external networks](#support-for-clouds-with-multiple-external-networks)
@@ -15,9 +22,13 @@
15
22
-[Create E2E test environment](#create-e2e-test-environment)
16
23
-[OpenStack](#openstack)
17
24
-[DevStack](#devstack)
25
+
-[Server side](#server-side)
26
+
-[CAPO side](#capo-side)
18
27
-[Running E2E tests using rootless podman](#running-e2e-tests-using-rootless-podman)
19
28
-[Host configuration](#host-configuration)
20
29
-[Running podman system service to emulate docker daemon](#running-podman-system-service-to-emulate-docker-daemon)
30
+
-[API concepts](#api-concepts)
31
+
-[`referencedResources`](#referencedresources)
21
32
22
33
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
23
34
@@ -52,42 +63,28 @@ After generating `infrastructure-components.yaml`, replace the `us.gcr.io/k8s-ar
52
63
53
64
## Testing Cluster Creation using the 'dev-test' ClusterClass with Tilt
54
65
55
-
This guide demonstrates how to create a Kubernetes cluster using ClusterClass, specifically designed for a development environment. It includes initializing a Kind cluster, configuring secrets, and applying ClusterClass to deploy your cluster with Tilt.
66
+
This guide demonstrates how to create a Kubernetes cluster using a ClusterClass, specifically designed for a development environment. It includes configuring secrets, applying the ClusterClass, and creating a cluster with Tilt.
56
67
57
-
### Creating a Kind Cluster
58
-
59
-
Create a Kind cluster. This process involves the initialization of Cluster API providers for OpenStack.
68
+
The `dev-test` ClusterClass is designed for development.
69
+
This means that it is using the latest (potentially unstable) API version.
70
+
The defaults are also aligned with the devstack setup (documented below) to make it as easy as possible to use in a development flow.
71
+
However, this also means that it may *not* be well suited for general usage.
60
72
61
-
```bash
62
-
kind create cluster
63
-
export CLUSTER_TOPOLOGY=true
64
-
clusterctl init --infrastructure openstack
65
-
```
66
-
67
-
### Secret Configuration
68
-
69
-
CAPO needs a clouds.yaml file in order to manage the OpenStack resources needed for the Cluster. This should be supplied as a secret named `${CLUSTER_NAME}-cloud-config`. You can create this secret for example with:
You can also make Tilt create it for you when you run `tilt up`, more on that in the next section.
76
-
77
-
## Developing with Tilt
73
+
### Developing with Tilt
78
74
79
75
We have support for using [Tilt](https://tilt.dev/) for rapid iterative development. Please visit the [Cluster API documentation on Tilt](https://cluster-api.sigs.k8s.io/developer/tilt.html) for information on how to set up your development environment.
80
76
81
-
Default values align with the devstack setup, as documented below. When specifying the `KUBERNETES_VERSION`, ensure an image named `ubuntu-2204-kube-{{ KUBERNETES_VERSION }}`is available in your environment, corresponding to that Kubernetes version.
82
-
For using Tilt with ClusterClass, update your `tilt-settings.yaml` file as described:
77
+
The `Tiltfile` in the Cluster API repository can be used as is with CAPO, but we need to add some configuration.
78
+
For using Tilt with ClusterClass, update your `tilt-settings.yaml` file (located in the root of the CAPI repository) as described:
83
79
84
80
```yaml
81
+
template_dirs:
82
+
openstack:
83
+
# Make Tilt aware of the CAPO templates
84
+
- ../cluster-api-provider-openstack/templates
85
+
85
86
kustomize_substitutions:
86
87
CLUSTER_TOPOLOGY: "true"
87
-
# Define the name of your cluster (e.g., "dev-test")
88
-
CLUSTER_NAME: "<cluster_name>"
89
-
# Desired Kubernetes Version for Your Cluster (e.g., "v1.28.5")
90
-
KUBERNETES_VERSION: "<kubernetes_version>"
91
88
# [Optional] SSH Keypair Name for Instances in OpenStack (Default: "")
When you are happy with the configuration, start the environment as explained in the CAPI documentation.
105
+
Open the Tilt dashboard in your browser.
106
+
After a while, you should be able to find resources called `CAPO.clusterclasses` and `CAPO.templates`.
107
+
These shoud correspond to what exists in the `templates` folder and you should see widgets for applying and deleting them.
108
+
109
+
**Note:** When you apply a cluster template, there will be a `KUBERNETES_VERSION` variable.
110
+
This variable is used to pick the image used!
111
+
Ensure that an image named `ubuntu-2204-kube-{{ KUBERNETES_VERSION }}` is available in your environment, corresponding to that Kubernetes version.
112
+
113
+
**Note:** All clusters created from the dev-test ClusterClass will require a secret named `dev-test-cloud-config` with the `clouds.yaml` to be used by CAPO for interacting with OpenStack.
114
+
You can create it manually or see below how to make Tilt automate it.
115
+
116
+
### Automatically applying kustomizations with Tilt
117
+
118
+
This explains how to automatically create the secret containing `clouds.yaml`.
119
+
The same procedure can be used for any other things you want to create in the cluster.
120
+
104
121
Ensure the specified path (`/path/to/kustomize/secret/configuration`) contains both the `clouds.yaml` file and a `kustomization.yaml` file. The `kustomization.yaml` should define the necessary resources, such as a Kubernetes secret, using the `clouds.yaml` file.
105
122
106
123
For example, if you want to automatically create a secret named `dev-test-cloud-config` with the content of your `clouds.yaml` every time you do `tilt up`, you could do the following.
@@ -144,11 +161,51 @@ secretGenerator:
144
161
type: Opaque
145
162
```
146
163
147
-
If you now add `/tmp/capo-dev` to the `additional_kustomizations`, tilt will automatically apply
148
-
the secret when you do `tilt up`.
164
+
If you now add `/tmp/capo-dev` to the `additional_kustomizations`, tilt will automatically apply
165
+
the secret.
149
166
150
167
To check that the kustomization produces the desired output, do `kustomize build /tmp/capo-dev`.
151
168
169
+
## Using the 'dev-test' ClusterClass without Tilt
170
+
171
+
If you want to use the ClusterClass without Tilt, you will need to follow these steps instead of the above.
172
+
173
+
### Creating a Kind Cluster
174
+
175
+
Create a Kind cluster and deploy CAPO.
176
+
177
+
**Note:** As the dev-test ClusterClass is made for development, it may be using a newer API version than what is in the latest release.
178
+
You *will need* to [use local artifacts](https://cluster-api.sigs.k8s.io/clusterctl/developers#use-local-artifacts) for this to work in most cases!
179
+
180
+
```bash
181
+
kind create cluster
182
+
export CLUSTER_TOPOLOGY=true
183
+
clusterctl init --infrastructure openstack
184
+
```
185
+
186
+
### Secret Configuration
187
+
188
+
CAPO needs a clouds.yaml file in order to manage the OpenStack resources needed for the Cluster. This should be supplied as a secret named `dev-test-cloud-config`. You can create this secret for example with:
@@ -445,4 +502,4 @@ This sections goal is to gather various insights into the API design that can se
445
502
446
503
Starting from v1alpha8 both `OpenStackMachineStatus` and `BastionsStatus` feature a field named `referencedResources` which aims to include fields that list individual IDs of the resources associated with the machine or bastion. These IDs are calculated on machine or bastion creation and are not intended to be changed during the object lifecycle.
447
504
448
-
Having all the IDs of related resources saved in the statuses allows CAPO to make easy decisions about deleting the related resources when deleting the VM corresponding to the machine or bastion.
505
+
Having all the IDs of related resources saved in the statuses allows CAPO to make easy decisions about deleting the related resources when deleting the VM corresponding to the machine or bastion.
0 commit comments