✨ Prepare context with cluster

[aaronjwood]

The goal of this is to have the context ready to be used by the time Reconcile is called on a controller. I've been seeing lots of code like this:

func (m *myCtrl) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
	path := logicalcluster.Name(req.ClusterName).Path()
	clusterCtx := kontext.WithCluster(ctx, logicalcluster.Name(path.String()))
	myType := &foo.MyType{}
	err := m.Get(clusterCtx, types.NamespacedName{Namespace: req.Namespace, Name: req.Name}, myType)
	...
}		

I don't see why controllers need to do this over and over. With the context having the cluster set this repetitive boilerplate can be eliminated to something like:

func (m *myCtrl) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
	myType := &foo.MyType{}
	err := m.Get(ctx, types.NamespacedName{Namespace: req.Namespace, Name: req.Name}, myType)
	...
}

[kcp-ci-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign sttts for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• DOWNSTREAM_OWNERS

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

[kcp-ci-bot]

Hi @aaronjwood. Thanks for your PR.

I'm waiting for a kcp-dev 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.

[kcp-ci-bot]

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.

📝 Please follow instructions in the contributing guide to update your commits with the DCO

Full details of the Developer Certificate of Origin can be found at developercertificate.org.

The list of commits missing DCO signoff:

• 73900a3 Prepare context with cluster

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.

[embik]

Hey @aaronjwood, thank you for your contribution!

I totally see that the two lines in question feel repetitive, but I am concerned that we are diverging from upstream then. In addition, you can use this controller-runtime fork against non-kcp environments as well (and that's intended, as you might have a mixture of talking to kcp and to vanilla Kubernetes on different sides), and I'm not sure that injecting the cluster key into context unconditionally is a good idea.

@sttts WDYT?

[sttts]

How about https://github.com/kcp-dev/controller-runtime/blob/kcp-0.17/pkg/kcp/helper.go#L29 ? Keeps it out of the actual reconciler.

Am also a little hesitent to introduce too much magic, especially in the light of kubernetes-sigs#2726.

[aaronjwood]

Thanks for the review guys. I'm fine to close this if it's not the direction we want to go. Just so I understand, when we say we're diverging from upstream with this, how is it different from 'ClusterNamebeing added in theRequest` struct?

[sttts]

Upstream will follow a mgr.GetCluster(req.ClusterName)) pattern, i.e. an explicit way to get the whole cluster interface, not only the client (which happens to have a context, many other methods of Cluster don't). Hence, we are forced to have some code that explicitly specifies the cluster name.

[aaronjwood]

I see, thanks. I'll close this out.