Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Launch Darkly Crossplane Provider #170

Open
felixlut opened this issue Aug 2, 2023 · 4 comments
Open

Launch Darkly Crossplane Provider #170

felixlut opened this issue Aug 2, 2023 · 4 comments

Comments

@felixlut
Copy link
Contributor

felixlut commented Aug 2, 2023

Hey!

I don't know if this is the correct forum to raise this question, but here we go.

My organization is currently looking into Launch Darkly and how to roll it out to our developers. We’ve investigated this Terraform provider, and think that it fills most of our use-case, but we also been interested in the Crossplane project lately. It has a lot of similarities with Terraform, with the difference that you provider your resources as Kubernetes yaml files as opposed to Terraform HCL.

One option that we are exploring is to use upjet to generate a Crossplane provider for Launch Darkly, but before doing so we wanted to reach out to you to see if you have any plans of maintaining one yourselves?

The upjet documentation have a quite extensive documentation for how this process would work.

Thanks in advance!

@ldhenry
Copy link
Collaborator

ldhenry commented Aug 2, 2023

Hey @felixlut,

I've just added an internal feature request for a Crossplane provider. As of today, we do not have any immediate plans to build a Crossplane provider but I will leave this issue open so others can upvote it.

In the meantime, have you considered using the provider-terraform? I have never tried this, but it seems like it could work.

Also, if you do end up generating a LaunchDarkly provider with upjet, please share your results here. I'm curious to see how it turns out.

Thanks,
Henry

@felixlut
Copy link
Contributor Author

felixlut commented Aug 2, 2023

@ldhenry the Terraform provider is an alternative that we are considering as well. Currently we're leaning towards either that, or to try and generate our own native Crossplane provider.

Our use-case for this is to have my users (i.e., the rest of development at my org) write their feature flags as Kubernetes yaml:s and handle them in a gitops fashion, together with their regular k8s deployments.

The issue with the terraform approach is that it still requires handling of the statefile, which we want to abstract away if possible. Terraform by nature is also quite rigid, and has a tendency to get pissy about drift, eg someone deleted something manually, and terraform notices it and crashes, as opposed to just recreating it. It's a great tool, but if you want flexibility you need to bend over backwards sometimes

@ldhenry
Copy link
Collaborator

ldhenry commented Aug 2, 2023

That makes a ton of sense. Thanks for sharing - I've added this info to the feature request.

@felixlut
Copy link
Contributor Author

For anyone interested how the experimentation went we figured out the following:

  • Maintaining an in-house provider ourselves proved to be too much work in the end, and the Crossplane terraform-provider proved to be the easier alternative.
  • While it was easy to get up and running from the start with upjet, multiple issues kept popping up, and as a small team we couldn't keep up.
  • Running small Terraform modules with Crossplane proved very efficient however! Turns out that the pains of distributing Terraform across your org is largely negated by them not needing to care about anything but the inputs (no s3 buckets for state, terraform pipelines, etc)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants