Launch Darkly Crossplane Provider

[felixlut]

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]

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]

@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]

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

[felixlut]

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)

[ldhenry]

Hey @felixlut, we finally got around to publishing a Crossplane provider (generated from upjet). You can check it out here or in the Upbound marketplace.

[felixlut]

Cool, I'll have to check that out 🚀

For what it's worth the Crossplane/Terraform solution listed above have actually worked pretty well for over 1y at this point. Most issues we've faced have been related to running Terraform within Crossplane (unlocking state after freak accidents for instance), so actually having a proper Crossplane provider sounds great 😁

[ldhenry]

Thanks for sharing that. If the Terraform with Crossplane approach is working for you then keep doing it. However, if you do decide to try our Crossplane Provider let us know how it goes. I'd be curious to know if we managed to resolve some of the issues you alluded to earlier.