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
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: