✨ feat: accept resource mutators in Move operation

[takirala]

What this PR does / why we need it:

As a developer I would like to move capi resources from one cluster to another cluster and while doing so, i would want to control the namespace the resources are created in the target cluster. Right now, when i perform a move operation, clusters are always moved to the same namespace on target cluster as they are originally created in the originating cluster. I want to be able to control this so that I can move resources from multiple clusters to a single cluster and still organize them by namespace post move operation.

This PR takes the approach discussed in #7940 (comment) An alternative to this PR was initially proposed at #7941 but that approach seemed inflexible. So this PR overrides #7941

Which issue(s) this PR fixes:
Fixes #7940

[k8s-ci-robot]

Hi @takirala. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[fabriziopandini]

/ok-to-test

[fabriziopandini]

/ok-to-test
/area clusterctl

[takirala]

The tests are failing with

sigs.k8s.io/cluster-api/cmd/clusterctl/client/cluster
  Incompatible changes:
  - ObjectMover.Move: changed from func(string, Client, bool) error to func(string, []ResourceMutatorFunc, Client, bool) error
  Compatible changes:
  - ResourceMutatorFunc: added
sigs.k8s.io/cluster-api/cmd/clusterctl/client
  Incompatible changes:
  - MoveOptions: old is comparable, new is not
  Compatible changes:
  - MoveOptions.ExperimentalResourceMutators: added
make: *** [Makefile:568: apidiff] Error 1

I imagine this is expected as we need to change the interface. Any advice on how can I move forward or any other advice (accept the the breaking change VS making changes backwards compatibe - i don't know how though) cc @fabriziopandini @sbueringer ?!

[fabriziopandini]

pull-cluster-api-apidiff-main is not a blocking job, it is just a warning for reviewers to look at what is changed in our public API

[dlipovetsky]

Will we be able to release in a 1.3.x patch, given the clusterctl/client/cluster go API change? Or will this need to wait for the first 1.4 release?

[sbueringer]

In general our policy today doesn't allow feature backports (so it has to wait even if it wouldn't change the API)

[Jont828]

Thanks for the contribution! I don't see anything that looks wrong on a first pass. Have you been able to try running this to move a cluster based on the use case you outlined?

[takirala]

Have you been able to try running this to move a cluster based on the use case you outlined?

@Jont828 yes! I have validated the following scenario:

cluster A (from-kubeconfig cluster):

• capi resources were in default namespace
• they were backed by capa provider

cluster B (to-kubeconfig cluster):

• capi components were pre installed and then move was performed
• capi resources were moved to foobar namespace
• everything was healthy (ensured foobar takijan25 Provisioned 68m status)
• deleted the cluster and all its resources were cleaned up by capa pod running on cluster B.

[takirala]

/test pull-cluster-api-test-mink8s-main

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: b5c246c338f721cc3b0ed465b723e21fca1327ef

[fabriziopandini]

I will be happy to get this in this release if we can address comments before the code freeze (around the 15th of March, please check the exact date)

[dlipovetsky]

While reviewing the code with @takirala, we realized that there is a small bug here, namely that we call ensureNamespaces with the unmutated objects, so we end up creating all the namespaces from the source cluster on the target cluster; these namespaces are not needed if mutators change the namespace.

https://github.com/kubernetes-sigs/cluster-api/pull/7966/files#diff-3458bf9e9c245fe801573500c33de535f05d3a5887f080a405b819e3c0fed415R337

[takirala]

@fabriziopandini @ykakarap all the previous comments are addressed to the best of my understanding - could you PTAL again ? Thanks!

[takirala]

Ping @fabriziopandini @ykakarap can you PTAL again ? TIA!

[k8s-ci-robot]

@takirala: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-cluster-api-apidiff-main	a8b898f	link	false	/test pull-cluster-api-apidiff-main

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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. I understand the commands that are listed here.

[takirala]

Ping @fabriziopandini @ykakarap can you PTAL again ? TIA!

[fabriziopandini]

Great work, and sorry for the lack of answer but between KubeCon and other internal events April was mostly an AFK month for me.

Unfortunately, it seems that both @ykakarap and @Jont828 didn't have the bandwidth to take a look at this PR too, but I think the implementation is sound and if they have some feedback there is room to get them addressed before the release.
/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 7fd99f31dcdf3f58d85ac7ee6b2068ae663cedda

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fabriziopandini

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [fabriziopandini]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment