Repository navigation
Conversation
schmidax
force-pushed
the
migration/capi-v1.11
branch
from
August 21, 2026 09:10
baa2fc0 to
331d9f2
Compare
Member
|
@schmidax What about the failing checks? Is there an image available somewhere, or do I need to build one myself for testing? |
Author
|
@Nils98Ar I'll take a look at the failing checks. And I haven't uploaded the image anywhere yet. |
- Upgrade CAPI dependency from v1.8.1 to v1.11.0 - Update import paths to v1beta1/v1beta2 locations - Use deprecated v1beta1 conditions packages (Stage 1) - Fix API signature changes (external.Get, predicates) - Fix ClusterAddon webhook (CustomValidator interface) - Fix Helm chart templates (dynamic namespaces) - Add MIGRATION.md documentation Per CAPI v1.11 migration guide: https://release-1-11.cluster-api.sigs.k8s.io/developer/providers/migrations/v1.10-to-v1.11 Signed-off-by: Axel Schmidt <axel.schmidt@rz.uni-augsburg.de>
- Upgrade CAPI dependency from v1.8.1 to v1.11.0 - Update import paths to v1beta1/v1beta2 locations - Use deprecated v1beta1 conditions packages (Stage 1) - Fix API signature changes (external.Get, predicates) - Fix ClusterAddon webhook (CustomValidator interface) - Fix Helm chart templates (dynamic namespaces) Per CAPI v1.11 migration guide: https://release-1-11.cluster-api.sigs.k8s.io/developer/providers/migrations/v1.10-to-v1.11 Signed-off-by: Axel Schmidt <axel.schmidt@rz.uni-augsburg.de>
- Use cluster.Spec.Topology.ClassNamespace when looking up ClusterStackRelease - Fallback to cluster.Namespace if classNamespace is not set - Supports CAPI v1.11+ cross-namespace ClusterClass references Signed-off-by: Axel Schmidt <axel.schmidt@rz.uni-augsburg.de>
Signed-off-by: Axel Schmidt <axel.schmidt@rz.uni-augsburg.de>
Signed-off-by: Axel Schmidt <axel.schmidt@rz.uni-augsburg.de>
schmidax
force-pushed
the
migration/capi-v1.11
branch
from
September 17, 2026 07:22
bb549c6 to
e19e719
Compare
Signed-off-by: Axel Schmidt <axel.schmidt@rz.uni-augsburg.de>
Signed-off-by: Axel Schmidt <axel.schmidt@rz.uni-augsburg.de>
…he owning object external.Get in CAPI >= 1.11 uses the namespace of the reference instead of an explicit namespace argument. A ClusterStack with a providerRef without namespace (as documented) could therefore not find its template anymore. Always resolve the template in the namespace of the ClusterStack, like before, default the namespace of the Cluster references used for the addon builtins and add a test for a providerRef without namespace. Signed-off-by: Jan Schoone <6106846+jschoone@users.noreply.github.com>
…p in the workload cluster cleanUpResources talks to the workload cluster, where resources without a namespace belong to the addon namespace (kube-system). The namespace of the ClusterAddon object in the management cluster is not meaningful there. Signed-off-by: Jan Schoone <6106846+jschoone@users.noreply.github.com>
…terClasses are in use Clusters of any namespace can use the ClusterClasses of a namespace since CAPI 1.11. The in-use checks of the ClusterStack and ClusterStackRelease webhooks and controllers only looked at the clusters of the own namespace, so a ClusterStackRelease could be deleted while a cluster in another namespace still used its ClusterClass, and clusters of the own namespace using a ClusterClass of another namespace were wrongly counted. Add pkg/clusterclass with a helper listing the clusters that use the ClusterClasses of a namespace and a test for getUsedClusterClasses. Signed-off-by: Jan Schoone <6106846+jschoone@users.noreply.github.com>
Add support for CAPI >= 1.11 (v1beta2)
The integration tests created their workload cluster from the kindest/node v1.26.6 image. On current runner kernels kube-proxy and kindnet of that image crash (the iptables of its Debian 11 base no longer works), so the node never becomes ready and the Test Code check fails. Use kind v0.31.0 with its node image v1.35.0, detect the container runtime instead of forcing docker (KIND_EXPERIMENTAL_PROVIDER selects another one) and move hack/kind-dev.sh to the same Kubernetes version. Signed-off-by: Jan Schoone <6106846+jschoone@users.noreply.github.com>
The 3 second timeout is too short for the specs that wait for the cluster addon to apply Helm charts to the kind cluster. Raise it to 30 seconds, the specs still return as soon as the condition is met. Signed-off-by: Jan Schoone <6106846+jschoone@users.noreply.github.com>
When a cluster switches to a release of the same Kubernetes version, the objects of the old release that are not part of the new one are deleted. The objects of the old release were collected with the stages of the clusteraddon.yaml of the new release, but from the charts of the old release. An addon that only exists in the old release (removed from the cluster stack) was therefore never found and its objects stayed in the workload cluster. Read the stages from the clusteraddon.yaml of the old release. Signed-off-by: Jan Schoone <6106846+jschoone@users.noreply.github.com>
…cluster stack The integration tests used releases in the old cluster stack format (docker-ferrol 1.27), with a single Helm chart per release and a version label on the objects. Replace them with two releases built from the docker/scs cluster stack of cluster-stacks (Kubernetes 1.35), which use the addon stages: - the hook applies the gateway-api, cni and metrics-server addons, including a value that is templated from the Cluster object, - a release with a changed addon updates the objects, - a release without the gateway-api addon removes its objects. test/releases/README.md describes how the releases are built. The old releases stay for the unit tests of the controllers. Signed-off-by: Jan Schoone <6106846+jschoone@users.noreply.github.com>
go mod tidy after the update to kind v0.31.0 removes the checksums of v0.30.0. Signed-off-by: Jan Schoone <6106846+jschoone@users.noreply.github.com>
Contributor
…PI >= 1.13 Cluster API 1.13 and newer send the runtime hook request with a v1beta2 Cluster. The hook server decodes it as v1beta1, where the class is spec.topology.class; in v1beta2 it is spec.topology.classRef.name. The class was therefore empty and the hook record key (name/namespace/clusterclass) was the same for every ClusterClass of a cluster. After the first upgrade of a cluster, every further upgrade of the same cluster in the same CSO process then skipped the patch of the ClusterAddon: BeforeClusterUpgrade returned success without applying the addons of the new release and the ClusterAddon stayed ready. Seen with CAPI 1.13.7: after 1.35 -> 1.36 the nodes ran v1.36.6 while Cilium, the cloud-controller-manager and the Cinder CSI plugin were still on the 1.35 versions. If the class is missing in the request, read the Cluster from the API server (served as v1beta1 by Cluster API 1.11 to 1.14). This uses the API reader of the manager and not the cached client: Cluster API calls the hook right after it has seen the new class, and the cache of the CSO can still have the previous one (a first version that read from the cache did not fix the skipped hook). Requests of Cluster API 1.11 and 1.12 carry the class and are handled as before. A missing topology no longer causes a nil pointer dereference. No change of the Cluster API version of the CSO. Signed-off-by: Jan Schoone <6106846+jschoone@users.noreply.github.com>
revive reports unused-receiver for the List method of fakeReader in extension/hooks_test.go (golangci-lint 2.2.1 in the CI): extension/hooks_test.go:58:7: unused-receiver: method receiver 'f' is not referenced in the method's body, consider removing or renaming it as _ (revive) Signed-off-by: Jan Schoone <6106846+jschoone@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it:
Migrate cluster-stack-operator from CAPI v1.8.1 to CAPI v1.11.0 (Stage 1).
Key changes:
This is a Stage 1 migration only — conditions still use the clusterv1.Conditions type via the deprecated v1beta1 packages. Migration to metav1.Conditions (Stage 2/3) is intentionally deferred.
Special notes for your reviewer: