Resource for feature flags

[JonasBak]

Describe the feature request

I would like to be able to manage feature flags through terraform.

Background

The use case for this is that if we're able to do what's described in https://github.com/Unleash/terraform-provider-unleash/issues/125, it would be nice for teams to have the option to define feature flags using terraform.

I see this in the README.md:

Because feature flags should be short-lived, we do not support managing feature flags through Terraform. Feature flags should be managed directly in Unleash.

But I also see that the expected lifetime of some of the toggle types is up to 40 days, and some are permanent. I think these types would be nice to manage through terraform. We do a lot of frequent changes through terraform, and I would think that for us even the types with an expected lifetime of 7 days would be appropriate to manage with terraform.

I also see in the README.md:

If you're interested in using Terraform to manage feature flags, you can use philips-labs/unleash provider that supports managing feature flags.

We could use that provider, but I think it would be better to use the official provider, and not mix both (we already use features only available in the official provider).

Solution suggestions

Implement resources to manage feature flags.

[gastonfournier]

Hi @JonasBak! Can you go into more details into the specific use case? Another reason why we did not want to implement this resource is because features is the resource that changes the most, so keeping up with the new features around feature toggles would be a huge burden on us, or the functionality in Terraform will always be lagging (e.g. feature dependencies or strategy variants).

Maybe there's a case for long lived flags, but I wonder how deep into the weeds should we go. It would be nice if we have a specific use case rather than building this in a flexible way using our APIs. What I'm thinking is more in the line of: this is how we'd like it to be configured (start with what the configuration should be on Terraform side), and then deciding if we should support that, rather than allowing customers to have all functionality we have in feature flags through our API.

We are in contact with Philips lab as well and they've collaborated a lot with the development of the official provider, and it's an open source product. We can have an example on how to use it for a specific purpose and then based on that experience decide what we want to do. This would be another approach as well.

In any case, I hope that helps explain the reasoning why this was not built, but now that there's a more specific use case, perhaps we can use it to refine what to do.

[JonasBak]

The reason why we want this is because this is how we manage all of our stuff across a bunch of different services; using terraform. It makes it easier to document all working "components" of an application and track changes from a single repo, and I would consider some types of feature toggles as a "part of" an application.

I think the main way we would use this is probably by defining features (especially long-lived ones that are a "part of" the application) using terraform. I think that some teams would probably use the Unleash frontend to enable/disable the features, as "non-developers" often want to be able to enable new features, or enable a kill-switch. I also think some teams might prefer to enable/disable features using terraform.

When it comes to keeping up with new features, one option that could reduce the workload of keeping it up to date would be to implement it as a "_yaml-type or _json-type resource" (like unleash_feature_flag_yaml) that some providers use, that just takes the body of the feature flag as input, and posts it to the appropriate endpoint. That would mean that you wouldn't need to implement each new field in terraform. One example of this is the datadog_service_definition_yaml resource.