search

crossplane-contrib / provider-gcp

Crossplane GCP provider
Apache License 2.0
127 stars 101 forks source link

Have you considered using Config Connector? #283

Open bgrant0607 opened 3 years ago

bgrant0607 commented 3 years ago

I didn't see any other issues, PRs, or docs answering this question.

GCP has a supported KRM-based provider: https://cloud.google.com/config-connector/docs/overview

It supports a significant number of resources: https://cloud.google.com/config-connector/docs/reference/overview

Have you considered using it?

negz commented 3 years ago

Hi Brian,

Great question! We have considered using Config Connector, but we feel that a purpose built Crossplane provider offers a better experience for our community.

This experience comes largely from API consistency within the Crossplane ecosystem. We love the KRM and what it has done for open source control planes, but we’ve found that our community benefits from an even more opinionated API - we think of this as the Crossplane Resource Model, or XRM. Under this superset of the KRM things like credentials, status conditions, deletion policies, and references to other resources work the same no matter which provider you use. This prevents users having to build subtly different mental models (and software!) when they need to work with multiple providers - for example pairing provider-gcp with provider-sql, or provider-helm.

We’ve had a lot of success collaborating with the folks at AWS and Azure who are working on their KRM-based infrastructure controllers to generate XRM compliant Crossplane providers. We’ve adapted the codegen pipelines that build ACK and ASO to output open source Crossplane providers, and would love to chat about doing the same with Config Connector.

prasek commented 3 years ago

@bgrant0607 some more info on the ACK and ASO collaboration here: https://blog.crossplane.io/accelerating-crossplane-provider-coverage-with-ack-and-azure-code-generation-towards-100-percent-coverage-of-all-cloud-services/

would be great to do the same with GCP Config Connector!

/cc @jaypipes @davefellows

Zamyatin commented 3 years ago

Just a thought, but the folks at Google that support the Terraform / Ainsible / Pulumi providers use some provider-building tooling called "Magic Modules" (https://github.com/GoogleCloudPlatform/magic-modules) which does some magic to auto-update providers as API changes come out. Not sure how you'd fit your project in with MM, but it might be a huge boon to keep up with the APIs that Google spins out like, daily. :)

bgrant0607 commented 2 years ago

Some updates here:

Config Connector is now open source: https://github.com/GoogleCloudPlatform/k8s-config-connector

It's partly built on: https://github.com/GoogleCloudPlatform/declarative-resource-client-library

And partly on our Terraform provider: https://github.com/GoogleCloudPlatform/k8s-config-connector/tree/master/third_party/github.com/hashicorp/terraform-provider-google-beta

I assume we could use Config Connector resources in Crossplane compositions using the Kubernetes provider. That might be useful for existing Config Connector users.

Also, it looks like the terrajet provider doesn't have many resource types yet: https://github.com/crossplane-contrib/provider-jet-gcp/tree/main/apis

Config Connector has quite a few: https://github.com/GoogleCloudPlatform/k8s-config-connector/tree/master/samples/resources

In terms of API consistency, we have been working on making Config Connector kstatus compatible (https://github.com/crossplane/crossplane/issues/2672).

negz commented 2 years ago

Thanks for the updates @bgrant0607! I'm happy to see config connector has been open sourced. I'm supportive of folks using provider-kubernetes in combination with KCC if doing so makes sense for them. That said, I don't think it's sufficient as a replacement for a "true" Crossplane provider.

kstatus is great and something we may also adopt, but there are other useful patterns all Crossplane providers adhere to. For example external identity (the crossplane.io/external-name annotation), spec.forProvider and status.atProvider to distinguish external system concerns from "Crossplane knobs", and more recently spec.publishConnectionDetails to support publishing credentials etc to arbitrary secret stores. Apart from these schema concerns, our community benefits from Provider packaging, which allow Crossplane to automatically figure out the RBAC permissions it needs to compose resources (if so desired), and allows Configurations to depend on Providers. We love what you're doing with DCL and would happily support Google building a Crossplane provider if that's something you'd be interested in.

By the way, the directory you found for the Terrajet GCP provider is a "preview" build with only the most popular CRDs. We do this at the moment to workaround some of the issues that we've been seeing around CRD scaling (I noticed recently your KCC users are running into similar problems per https://github.com/GoogleCloudPlatform/k8s-config-connector/issues/650). Our "preview" build at https://github.com/crossplane-contrib/provider-jet-gcp/tree/release-0.2-preview/apis has many more CRDs (I believe more even than KCC at the moment).