Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to use controller-runtime for ClusterWorkspaceType initializer #16

Open
MatousJobanek opened this issue Jul 7, 2022 · 5 comments
Labels
lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.

Comments

@MatousJobanek
Copy link

MatousJobanek commented Jul 7, 2022

Consider that I have a ClusterWorkspaceType and an initializer that is supposed to create an APIBinding. That initializer is watching a VirtualWorkspace of the given CWT, however, when it tries to create an APIBinding, then it fails with:

1.65719959317604e+09	ERROR	controller.clusterworkspace	Reconciler error	{"reconciler group": "tenancy.kcp.dev", "reconciler kind": "ClusterWorkspace", "name": "appp", "namespace": "", "error": "no matches for kind \"APIBinding\" in version \"apis.kcp.dev/v1alpha1\""}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	/home/mjobanek/go-workspace/src/github.com/kcp-dev/controller-runtime/pkg/internal/controller/controller.go:266
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
	/home/mjobanek/go-workspace/src/github.com/kcp-dev/controller-runtime/pkg/internal/controller/controller.go:227

The reason is that the rest mapper tries to do the discovery call before calling the POST for the APIBinding. But it does it for the VirtualWorkspace endpoint with the wildcard /clusters/* at the end of the URL, not with the name of the workspace that is being initialized /clusters/root:plane:usersignup:foo/:

I0707 13:13:13.510869       1 round_trippers.go:463] GET https://192.168.1.133:6443/services/initializingworkspaces/root:plane:usersignup:Appstudio/clusters/%2A/api/v1
I0707 13:13:13.510875       1 round_trippers.go:469] Request Headers:
I0707 13:13:13.510882       1 round_trippers.go:473]     Authorization: Bearer <masked>
I0707 13:13:13.510888       1 round_trippers.go:473]     Accept: application/json, */*
I0707 13:13:13.521749       1 round_trippers.go:574] Response Status: 404 Not Found in 10 milliseconds
I0707 13:13:13.521845       1 request.go:1372] body was not decodable (unable to check for Status): couldn't get version/kind; json parse error: json: cannot unmarshal string into Go value of type struct { APIVersion string "json:\"apiVersion,omitempty\""; Kind string "json:\"kind,omitempty\"" }
I0707 13:13:13.524075       1 round_trippers.go:574] Response Status: 200 OK in 13 milliseconds
1.6571995935242307e+09	ERROR	controller.clusterworkspace	Reconciler error	{"reconciler group": "tenancy.kcp.dev", "reconciler kind": "ClusterWorkspace", "name": "appp", "namespace": "", "error": "no matches for kind \"APIBinding\" in version \"apis.kcp.dev/v1alpha1\""}

There are two problems in the rest mapper code:

  1. The rest mapper doesn't use the cluster-aware client nor the cluster-aware round-tripper. But even if I modify the code so it uses the cluster-aware round-tripper, then I face the second problem:
  2. The context that is being passed as part of the discovery call is context.TODO() https://github.com/kubernetes/client-go/blob/release-1.23/discovery/discovery_client.go#L172 and not the one that is provided from the controller. This means that the context doesn't have the cluster name value so the cluster-aware round-tripper cannot do its job.
@MatousJobanek
Copy link
Author

I created a reproducer for this issue:
https://github.com/MatousJobanek/controller-runtime-example/tree/cwt-reproducer

  1. build & deploy the controller
  2. create workspace of the type Widget

@stevekuznetsov
Copy link

But it does it for the VirtualWorkspace endpoint, not for the actual workspace that is being initialized:

This is actually fine - the virtual workspace will proxy the request through to the correct cluster. The proximal issue here is that the request is not being made to the correct cluster.

@MatousJobanek
Copy link
Author

Yeah, I used the wrong wording - what I meant was that it's using the URL with the wildcard at the end instead of putting the name of the workspace that is being initialized. I fixed it in the description.

@kcp-ci-bot
Copy link

Issues go stale after 90d of inactivity.
After a furter 30 days, they will turn rotten.
Mark the issue as fresh with /remove-lifecycle stale.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@kcp-ci-bot kcp-ci-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 12, 2024
@kcp-ci-bot
Copy link

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

@kcp-ci-bot kcp-ci-bot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels May 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.
Projects
None yet
Development

No branches or pull requests

3 participants