Nic Cope
I've been thinking about this as I work on the Crossplane v2 prototype (https://github.com/crossplane/crossplane/pull/6255). I'm starting to cool on the idea. The idea of a ManagedResourceDefinition type occurred to me...
> I think the main value to users of an MRD would be giving us somewhere to record what connection secrets exist. We could do this without adding a new...
> Today you can browse the discovery API and look for resources in the categories crossplane and managed to discover types of MRs. Admittedly this doesn't tell you what provider...
> FWIW, we are [already](https://github.com/crossplane-contrib/provider-upjet-aws/blob/main/package/crds/accessanalyzer.aws.upbound.io_analyzers.yaml#L14) very close to this: Yeah I know. I'd like the package manager to enforce that though. Today it's up to provider authors [^1] to remember...
I've now flip flopped and am planning to stick with this for v2. There's a few other places I think it could be useful. One is that it gives us...
@dee0sap If all you're a after is to: 1. Delete the XR (from the API server) 2. Make sure its composed resources aren't deleted (from the API server) You should...
Bit of a tangent, but I'd prefer to reorganize `cmd/` to mostly contain only actual CLI entry points, with any supporting libraries moving out of `cmd/` and under `internal/`, or...
More on-topic: * Any time we make a package public we're committing to maintaining it as a library (caring about breaking changes etc). * If we do want to take...
It's worth noting that we _might_ actually want this behaviour in future. For example: * If we wanted a webhook to validate the `input` fields of a Composition. * If...