Missing support for "clusterctl.cluster.x-k8s.io/move" label since v1alpha4

[Endevir]

What steps did you take and what happened?

Hi!
I'm using custom Secret to provide credentials for OpenStack infrastructure provider.
Applied manifest like this (with clusterctl.cluster.x-k8s.io/move: "true" label, according to docs):

apiVersion: v1
kind: Secret
metadata:
  name: capi-clouds-config-secret
  namespace: capi-management-cluster
  labels:
    clusterctl.cluster.x-k8s.io/move: "true"
data:
  cacert: $CACERT_BASE64
  clouds.yaml: $CLOUDS_YAML_BASE64

But during clusterctl move --to-kubeconfig=kube.yaml --namespace capi-management-cluster --dry-run -v 10

I run into this line in logs: Excluding secret from move (not linked with any Cluster) name="capi-clouds-config-secret" and have secret skipped (breaking provider reconciliation in target cluster).

What did you expect to happen?

Secret with clusterctl.cluster.x-k8s.io/move: "true" label should also be moved into target cluster

Cluster API version

1.5.3

Kubernetes version

v1.27.6

Anything else you would like to add?

Seems like tracking clusterctl.cluster.x-k8s.io/move label was dropped since v1alpha4 (API for v1alpha3 still contains ClusterctlMoveLabel mentions).

However, label still is mentioned in docs: https://cluster-api.sigs.k8s.io/clusterctl/provider-contract.html#move

Label(s) to be applied

/kind bug
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

[killianmuldoon]

/triage accepted

There's definitely a bug in the implementation here - thanks for catching it. I think there's two seperate issues.

1. Secrets in the provider namespace should be moved without needing a label.
2. Secret should not be excluded from move if they have the correct label.

AFAICT neither of these cases are working right now and we need a fix.

/help

[k8s-ci-robot]

@killianmuldoon:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/triage accepted

There's definitely a bug in the implementation here - thanks for catching it. I think there's two seperate issues.

1. Secrets in the provider namespace should be moved without needing a label.
2. Secret should not be excluded from move if they have the correct label.

AFAICT neither of these cases are working right now and we need a fix.

/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[killianmuldoon]

/triage accepted

[sbueringer]

@killianmuldoon Did #9694 fix (only) 1?

[killianmuldoon]

According to #9694 (comment) both cases were working for the user. I'm not sure if it's tested properly though. I think we should add a help wanted here and get someone to ensure the tests are covering that case.

/help

[fabriziopandini]

#9694 should have fixed both, we can eventually re-open if someone reports issues again
/close

[k8s-ci-robot]

@fabriziopandini: Closing this issue.

In response to this:

#9694 should have fixed both, we can eventually re-open if someone reports issues again
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.