I'm open to other ideas here.

What I'd like to avoid is using v2 or namespaced in the API group.

I'd like to avoid v2 because it creates confusing API versions: e.g. ec2.aws.v2.crossplane.io/v1beta2. Is it v2 or v1beta2 or both? What happens if someday we want to introduce Crossplane v3? Would we be in a position where we need to change the API group again, even if we didn't want to change anything about MRs?

I'd like to avoid namespaced because long term I expect all MRs will be namespaced.

If the eventual goal is to dispose of cluster scoped MRs in some future version of crossplane (v3+?) then would not any change to the API group in V2 become redundant?

Could this instead be solved by the introduction of an optional field say targetNamespace similar to how helm deployments are managed in fluxcd or destination.namespace from argocd? It's a pattern that users are likely already familiar with and would potentially reduce cognitive load.

Whilst this may result in a potentially breaking change across v2 -> some other future version the impact would likely be far smaller than changing the API group. I would also consider it less confusing to the end user who would have to know the difference between <service>.<provider>.upbound.io and <service>.<provider>.m.crossplane.io

I do not like the m for "managed"; it doesn’t encapsulate the difference between cluster-scoped MRs and namespaced. Maybe having ns wildly used in the community would convey better that we are dealing with namespaced MRs

If the eventual goal is to dispose of cluster scoped MRs in some future version of crossplane (v3+?) then would not any change to the API group in V2 become redundant?

I think this needs to be explicitly called out as a non-goal. I'm not convinced (yet?) that all of the current use-cases running in v1 are supported by v2. Until they are, or migration paths to equivalent functionality are identified, future deprecations should not be considered as likely.

What I'd like to avoid is using v2 or namespaced [or variants thereof] in the API group.

I don't think anyone loves m for managed but at this point no one has made a better suggestion that complies with the above constraints, so it's what we're likely to run with.

If the eventual goal is to dispose of cluster scoped MRs in some future version of crossplane (v3+?) then would not any change to the API group in V2 become redundant?

@mproffitt I don't follow most of your comment, sorry.

To make sure we're on the same page:

• We need to support cluster scoped and namespaced variants of the same MR, at least for a transition period.
• In many control planes these variants will both exist at the same time. e.g. You might have legacy, cluster scoped RDS Instance MRs running alongside namespaced Instance MRs.
• For this to be possible, the new namespaced MRs need to either have a different kind (e.g. Instance) or a different API group (e.g. rds.aws.crossplane.io) group.

The kind and API group is a top-level CRD field - it can't change from version to version of the CR. So is scope. This means to have cluster scoped and namespaced variants we need two CRDs, and therefore their kind or API group must differ.

I think this needs to be explicitly called out as a non-goal. I'm not convinced (yet?) that all of the current use-cases running in v1 are supported by v2. Until they are, or migration paths to equivalent functionality are identified, future deprecations should not be considered as likely.

@bobh66 Can you refresh my memory on those use cases (or link them if they're in another thread)?

At this point the intention is to drop cluster scoped MRs after some (long) transition period. I feel it's needlessly complicated to keep both forever.

Do we believe that in V1 we should natively support asynchronous reconciliation of resources or do we feel that is more of a V2 feature?

Can you clarify what you mean by async reconciliation of resources? It's not something on my radar.

I think this is probably what @blakeromano was referring to:

• Support async reconciliation  crossplane-runtime#790

That's not currently in scope for the initial v2 effort, but it could be considered for future releases.

What is the impact of this change on RBAC management for the providers? Assuming the RBAC manager continues to handle RBAC by default, are there any issues with Providers (and Crossplane) now needing access to (potentially) all namespaces? Given that everything is cluster-scoped now maybe the difference is irrelevant, but I think the impact needs to be documented.

Today when you install a provider the RBAC manager grants Crossplane (and the crossplane-admin role etc) access to all the MRs it defines - that'd still be true under this proposal. It'd just be granting that to all namespaces.

Do you feel this proposal needs to record that specifically?

How would crossplane manage observe-only resources for in-cluster MRs in this manner and how would that differ from the behaviour of say function-extra-resources Would an in-cluster O-O MR be able to observe across namespace or would you imagine this being entirely restricted to its own namespace

Sorry, I'm not following the question.

What do you mean by "in-cluster MRs"? A provider-kubernetes Object that observes a resource in the same cluster?

do you think that we should wait until we have a ReferenceGrant-like API before we enable/allow cross namespaced references on MRs?

If we want to have cross namespace references before then, i.e. with the release of v2, we'll need go further than what I've already done to introduce reference resolving to namespaced MRs in the following PRs:

• feat: enable namespaced reference resolution crossplane-runtime#843
• feat: enable namespaced references in generated resolvers crossplane-tools#110
• feat: support namespaced reference resolving crossplane-contrib/provider-upjet-aws#1799

That implementation does not have a namespace field for references, it assumes that a reference on a namespaced resource will be within the same namespace. So if we want to wait until we have some ReferenceGrant capability, then we are all good for now 😇

I feel like it might be a hard sell to not support this at launch. We're already seeing some push back about not being able to compose into other namespaces, let alone reference them. So I suspect not supporting references across namespaces might have a chilling effect on the uptake of namespaced MRs.

It seems like the ReferenceGrant API referenced in the gatewayapi docs seems highly generic. Apart from the fact that its in the gateway.networking.k8s.io/v1beta1, the functionality seems universally applicable. I also maintain a controller for composing ConfigMaps and Secrets that utilizes cross-namespace references, but supports an annotation-based convention for "allowing" a resource of that controller in another namespace to reference a resource. If ReferenceGrants were a generalized, standard API in Kubernetes, I would probably leverage that instead.

Aaaand, of of course, there's a SIG for that :) https://github.com/kubernetes-sigs/referencegrant-poc/

I feel like it might be a hard sell to not support this at launch

Thanks @negz - I've opened #6530 to track this cross namespace ability in the v2 roadmap.

I've been working/tinkering with some of the referencegrant things (kubernetes/enhancements#4387). We ended up not pushing it forward for now, but working on the prerequisites/more foundational concepts such as conditional and referential authorization instead.

ReferenceGrant is a non-trivial thing to get right securely, however, so I'd be interested in the more concrete use-cases for this. Is a decent compromise to allow either of the following?

a) Only allow referring to an MR across namespaces, if you already have access to get/update/"use" the referenced resource as per k8s RBAC (this can be enforced by a ValidatingAdmissionPolicy)
b) Allow referring from a namespaced MR to a cluster-scoped MR, potentially also requiring the same referential authorization check.