Raise exception: failed to wait for widget caches to sync: timed out waiting for cache to be synced

[vincent-pli]

I deployed the controller to my virtual workspace: root:gold:dogs , it successed to sync to a KinD physics cluster.
but the pod keep CrashLoopBackOff, there are error raised in the logs:

290 1.6632054553562376e+09  ERROR   Could not wait for Cache to sync        {"controller": "configmap", "controllerGroup": "", "controllerKind": "ConfigMap", "error": "failed to wait for configmap caches to sync:     timed out waiting for cache to be synced"}

300 1.6632054553565369e+09  ERROR   Could not wait for Cache to sync        {"controller": "widget", "controllerGroup": "data.my.domain", "controllerKind": "Widget", "error": "failed to wait for widget caches to     sync: timed out waiting for cache to be synced"}

Normally, it's caused by RBAC issue, I checked the clsuterrole, clusterrolebinding something, I think these are all as expectd, may I missing something?

[ncdc]

For the time being, there has to be at least 1 APIBinding somewhere before your controller can work. See kcp-dev/kcp#1183.

[vincent-pli]

@ncdc I do not think it's helpful, since I alreay have apibinding in my workspace but no apibinding for CRD widgets

[vincent-pli]

BTW, I want to know more about the kcp approach about the usage of virtual cluster.
When a tenant owner want to install a controller, normally, he/she need to install CRD, deployment, RBAC .etc.
but seems in kcp things is different, we adopt APIResourceSchema, apiexport, apibinding .etc...
@ncdc

[ncdc]

My apologies, I should have been clearer: you have to have 1 APIBinding for your APIExport (widgets, in this case).

This is an area that is severely under-documented at this point. We are working on it, though: https://hackmd.io/DJGw8YdQTaiPKz9a66Z6OQ?view

[vincent-pli]

That's great @ncdc , your documents clarified my confuse, expect to see the final version
BTW, why not adopt APIImport rather than APIBinding?

Another question is:
I guess API provider will not expose API to all workspace, so if a tanent owner want to use certain API, how does it let administrator know? do we plan to design a CRD maybe named APIRequirement, or whatever.

[ncdc]

why not adopt APIImport rather than APIBinding?

We went back and forth on what to call it. Import sounds like you're creating data (the API definition) in your workspace, which is not how it's implemented. We chose binding to indicate you're saying you want access to the API from somewhere else.

I guess API provider will not expose API to all workspace, so if a tanent owner want to use certain API, how does it let administrator know?

The API provider has to create ClusterRole/ClusterRoleBinding(s) that specify who (users and/or groups) is allowed to bind to their APIs. The easiest way to do this is to allow system:authenticated. If the API provider wanted to do something like only allow access to users who are e.g. paying a monthly subscription, that is possible, but would need to be designed & built separately.

do we plan to design a CRD maybe named APIRequirement

What would this do? (By the way, I'd encourage you to create discussions in the kcp repo to chat about these things - you'll get much more visibility there.)

[kcp-ci-bot]

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