Image resource not moved by clusterctl move due to missing clusterctl label on ORC Image CRD

[matofeder]

/kind bug

What steps did you take and what happened:

CAPO users rely on ORC to handle image uploads and reference the ORC Image resource inside OpenStackMachine via spec.image.imageRef.

When a cluster using this OpenStackMachine is moved using clusterctl move, the Image resource is not moved because the Image CRD itself lacks the required clusterctl.cluster.x-k8s.io label. Although the Image CR instance is labeled with clusterctl.cluster.x-k8s.io/move, the absence of this label on the CRD means clusterctl does not consider it during the move operation.

This breaks the smooth movement of the cluster state, resulting in OpenStack server resources becoming not ready.

See Cluster API docs for move: https://cluster-api.sigs.k8s.io/developer/providers/contracts/clusterctl.html?highlight=clusterctl.cluster.x-k8s.io%2Fmove-hierarchy#move

What did you expect to happen:

clusterctl move moves the ORC Image resource referenced in the OpenStackMachine

Anything else you would like to add:

I'm not sure whether this issue belongs to CAPO or ORC, but let's start the discussion here, as it is related to CAPI/CAPO.

Environment:

• Cluster API Provider OpenStack version (Or git rev-parse HEAD if manually built): v0.12.3
• Cluster-API version: v1.10.2
• OpenStack version:
• Minikube/KIND version: kind v0.29.0
• Kubernetes version (use kubectl version): 1.32.5
• OS (e.g. from /etc/os-release): Ubuntu 24.04.2 LTS

[lentzi90]

Strange. We do test this in the e2e tests but I wonder if the way we install ORC has something to do with it... Specifically, we use this image in the self-hosted test. As you can see, it has the move label. ORC is installed from this kustomization, which adds the cluster.x-k8s.io/provider: "runtime-extension-openstack-resource-controller" label to everything (including the CRDs). I suspect this is enough to make it work.

ORC can of course, be used stand-alone, so I don't think we should add any labels on the CRDs upstream. But, we could include a note about this in the CAPO docs. Do you think that would be enough?

CC @EmilienM

[matofeder]

ORC is installed from this kustomization, which adds the cluster.x-k8s.io/provider: "runtime-extension-openstack-resource-controller" label to everything (including the CRDs). I suspect this is enough to make it work.

It’s possible. I haven’t gone into all the details here, so I’m not sure exactly what Cluster API’s Tiltfile and clusterctl mechanisms in CAPO’s E2E tests are doing, but according to CAPI’s documentation, the clusterctl.cluster.x-k8s.io label is required for clusterctl move to enable processing that CRD. Here’s the corresponding code for reference: https://github.com/kubernetes-sigs/cluster-api/blob/main/cmd/clusterctl/client/cluster/objectgraph.go#L424 and CAPI docs: https://cluster-api.sigs.k8s.io/developer/providers/contracts/clusterctl.html?highlight=clusterctl%20move#move

I agree that proper documentation in CAPO should be sufficient to resolve this issue.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale