[RFC] Consider creating provider-gcp-beta

[hasheddan]

What problem are you facing?

As detailed in https://github.com/crossplane/provider-gcp/pull/308, having resources rely on v1beta1 GCP APIs precludes them from every reaching post-v1alphaX status because we cannot guarantee their stability. When fields are dropped or changed in the GCP API we are forced to either drop or change them in Crossplane because pinning the GCP API to a specific version blocks implementation of newer resources and features. However, we need to support v1beta1 GCP APIs in some capacity because users rely on some of the features.

How could Crossplane help solve your problem?

At the Crossplane Community Meeting on March 1st, 2020 there were a number of ideas discussed to solve this problem. The three primary variations are detailed below with pros and cons of each:

1. Add beta.<group>.gcp.crossplane.io resources for each v1beta1 GCP API group and keep all resources in the beta group as v1alphaX Crossplane APIs.
   • Pros: one install gives you all resource types
   • Cons: one install brings a ton of resource types with very similar APIs that could get mixed up, more resources affected by SDK version bumps
2. Create a new provider-gcp-beta that has resources for all of the v1beta1 GCP API groups that match the GVK of the provider-gcp v1 API resources.
   • Pros: You could theoretically use the same manifests between the two providers if you installed the opposite of the one you were using (obviously this is dependent on how much the v1beta1 and v1 APIs differ + if the Crossplane version was the same in the GVK, which it likely wouldn't be because all resources in provider-gcp-beta should remain v1alphaX)
   • Cons: Cannot install both providers at the same time, maintenance of two separate providers
3. Create a new provider-gcp-beta that has resources for all of the v1beta1 GCP API groups that have different GVK (i.e. <group>.gcp-beta.crossplane.io) than the provider-gcp v1 API resources.
   • Pros: You can install both providers at the same time, or only one if you only need it, each provider can updates its SDK versions at the desired frequency it chooses
   • Cons: maintenance of two separate providers

As could likely be gleaned from the Pros and Cons lists above, option three (3) was agreed upon as the best solution. However, this issue is meant to serve as an RFC for contributors and users to provide feedback on.

[muvaf]

I missed the community meeting, but I agree that a separate provider would make sense. I'm not sure about the naming though. There could be several v1beta* in GCP as well as v2beta* etc. So, having v1beta1.gcp.crossplane.io and v1.gcp.crossplane.io provider groups seems more accurate but also a recipe for confusion with CRD apiVersion.

Additionally, I think https://github.com/crossplane/crossplane/issues/2122 would be pretty helpful to folks who want to use beta APIs for some resources and v1 APIs for others.

[hasheddan]

I'm not sure about the naming though. There could be several v1beta* in GCP as well as v2beta* etc. So, having v1beta1.gcp.crossplane.io and v1.gcp.crossplane.io provider groups seems more accurate but also a recipe for confusion with CRD apiVersion.

Not sure I follow where you see the naming conflict here. It seems to me that having container.gcp.crossplane.io and container.gcp-beta.crossplane.io would be more in line with how provider groups differ today and would make it very clear what provider package the CRD came from.

[muvaf]

Are we sure that there will not be a v2 or v2beta1 that might necessitate a difference between gcp and v2 gcp, gcp-beta and v2beta1 gcp-beta?

[hasheddan]

@muvaf we cannot guarantee that, but the point of having the two different providers is not to map to a specific API for each but rather to have one where we can offer "stable" resources and one where we can offer "unstable" ones. So if there was a v2 API introduced for GKECluster for example I think we could have that in provider-gcp and and call it something like GKEClusterv2 or use the v2.container.gcp.crossplane.io nomenclature that you suggest. I think that is somewhat independent of the naming of the two providers though.

[muvaf]

Got it, sounds good to me. Thanks for the explanation!

[RealHarshThakur]

Option 3 does seem the best choice. There's one caveat end user would face and this has to be fixed upstream in Kubernetes. End user cannot kubectl explain <resource> based on the API group yet. https://github.com/kubernetes/kubernetes/pull/91295

[negz]

Option three has my vote! I'd go with beta.gcp.crossplane.io as the API group (presuming the beta part won't clash with some Google service named "Beta"?).

We'll need to do a thorough job of communicating these breaking changes - any idea how we can go about that given that we typically don't have provider scoped release notes or documentation?

[hasheddan]

This proposal is now in motion in https://github.com/crossplane/provider-gcp-beta. I think this is a great forcing function to introduce provider-specific release notes. According to governance, this is enforced on a per-provider level, but I would encourage us to go ahead and apply it to all providers under the crossplane org.