The Future of Cross-Identity Requests

[stevekuznetsov]

Today, we have *-cluster LIST and WATCH requests for partial metadata that cross resource identity boundaries in the DDSIF construct that is used in:

• resource scheduling
• permission claim labeling
• quota, garbage collection, namespace lifecycle

These requests have an ongoing cost to our system in that it is fundamentally against the core API paradigm to do cross-identity requests, so:

• doing this is very highly privileged, so any controller doing this must be part of the core and cannot be broken out
• these requests open us up to an entirely new class of behavior and bug surface, which costs time to maintain

For some class of usage, we know that every possible resource that can be scheduled will be served by the a virtual view, so we do not need a totally identity-agonostic request here and can instead dynamically start and stop informers against those views. An example is resource scheduling, where we can operate against the workload APIExport virtual views.

For the other class of usage, we simply get an efficiency benefit here, but it is very concretely only in the number of open connections against the kcp API server, and then only when multiple identities exist for the same group-resource. My intuition says that the single-group-resource many-identity case is and will remain fairly rare, so we must reconcile the magnitude of this efficiency increase with the ongoing cost to our codebase of this feature.

/cc @sttts @ncdc @davidfestal @MikeSpreitzer

[ncdc]

Something to also keep in mind: we also have identity-less CRs (from normal CRDs). These also need to be supported by quota, GC, namespace lifecycle.