Add v2 proposals#560
Conversation
| Known fidelity limits, stated honestly: CEL validation rules and other | ||
| server-side-only constraints may not round-trip through OpenAPI — the consumer-side | ||
| CRD can be *looser* than the provider's real validation, and the provider remains the | ||
| enforcing side (a consumer object that passes locally can still be rejected upstream; | ||
| that surfaces as a per-object sync condition, not silent loss). |
There was a problem hiding this comment.
Thinking out loud - couldn't this be fixed with a validation webhook? Install kbind as valdiation webhook on the consumer and proxy that to the provider or make a dry-run apply or something? That way the provider can still do the full validation. would be hacky though and the tradeoff mentioned would be ok i think.
There was a problem hiding this comment.
I don't want to have validation webhooks. In general, webhooks in any cluster require way more care and support, and from experience, you need to "have full access to the cluster" to stay on top of it. + it required a certificate pair, which adds dependency on cert-manager or another cert issuer. It just very hard to support in wide range of cluster configurations with wide range of setup permutations.
In general, it's easier to ship lightweight components if they do not have webhooks.
All this with the exception of CEL-based webhooks https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchconditions but it has limitations what it can do.
| ```sh | ||
| kubectl bind login https://mangodb.example.com # auth, cache token | ||
| kubectl bind catalog # list Exports/Collections | ||
| kubectl bind mangodb # bind an Export: |
There was a problem hiding this comment.
why not kubectl bind export mangodb? Mixing commands and custom export names seems wrong.
| most confusing API fields (`informerScope` vs `isolation` vs deprecated | ||
| `clusterScopedIsolation` vs CRD `scope`). | ||
|
|
||
| 2. **The object zoo.** A bind today touches up to ten CRDs: `APIServiceExportTemplate`, |
There was a problem hiding this comment.
Would be nice to see what apis go into v2 and which doesn't, like a table
4 participants
Summary
We have been integrating kube-bind with external systems, and we now understand what works and what does not for users to use it in a smooth, frictionless way.
I tried to draft an initial v2 proposal for Core and the remaining features.
The idea is to simplify the flow, make the core directory usable for the rest of the features, so one can use it separately as "syncer only". Historically, some of these features got globbed together, and in some cases, overengineered.
In addition, during the initial bootstrap, https://github.com/multicluster-runtime/multicluster-runtime did not exist. Now it does.
This serves as the initial discussion started. Please review and let me know wdyt?
What Type of PR Is This?
/kind feature
Related Issue(s)
Fixes #
Release Notes