launchdarkly_project resource requires environments when it shouldn't

[antonosmond]

Hi

The launchdarkly_project resource sets the environments attribute as required:

terraform-provider-launchdarkly/launchdarkly/resource_launchdarkly_project.go

Line 114 in 27ef679

Required: true,

This doesn't make sense as this differs from the LaunchDarkly API behaviour where environments are not required in order to create a project:
https://apidocs.launchdarkly.com/tag/Projects#operation/postProject

By declaring the environments attribute as required, it makes it difficult to use the separate launchdarkly_environment resource alongside the launchdarkly_project resource, as noted in the provider documentation.

IMO, the environments attribute should not be required. This would remove the unexpected behaviour compared to the LaunchDarkly API and would allow us to easily split our project creation from environment creation in our terraform.

[sloloris]

Hi @antonosmond,

Thank you for bringing this to our attention. It might not seem like it, but a lot of deliberation went into the decision to make environments required on projects when we released v2 of our provider (they are not required on the previous v1). If you are using v2 and up of our provider, we recommend you do not manage environments as their own resources unless you are not managing their parent project in Terraform. This is called out in both our environment and project resource documentation.

You are correct in pointing out that the LD API does not require environments to be specified upon project creation; however, environments are in fact required on projects, so that if you create a project without specifying any environments two (a production and a test) will automatically be created for you.

With the way Terraform works, however, this posed a problem: since the Terraform state should always reflect the existing configurations, users were not able to manipulate the default environments that were created with the project as they were never added to the Terraform state. This meant that they could not update or delete them; they would have been forced to import them first in order to be able to update and delete them. We received fairly regular complaints about this via our support channels, which also contributed to our decision to ultimately make them required.

With the v2 release - where environments are now required on projects - what we do under the hood is create a project with its default environments and then update them to match the environments specified on the user's resource configuration. This ensures that the project has its minimum of one environment and that that and any other environments will be tracked on the Terraform state from the outset, thus preventing any future user confusion around state / config file misalignment.

I recognize that it is less than ideal, and we do strive to make our Terraform resources parallel our API as much as possible, but given the constraints in this situation we were forced to deviate from that slightly. I apologize for any inconveniences this might cause but I hope this clears it up somewhat!

[antonosmond]

Thanks for the detailed response @sloloris.
I fully understand your explanation and can see this is not the fault of the provider.
That being said, maybe this is something that can be looked at by the LaunchDarkly team?

Here's some context:

We strive to have all of our infrastructure in code.
We also understand the importance of separation between production and non-production configuration/resources.

If we use the project resource to ensure we meet our first requirement of IaC, we're forced to put all env configs in the same terraform play. This means a single state file with both production & non-production resources i.e. we can't meet our second requirement of separation between prod & non-prod.
If we create the project in the LaunchDarkly Web GUI and then manage the envs in terraform, we're not meeting our first requirement of full IaC as the project creation would be click-ops.

One option would be to create separate projects for prod & nonprod but I'm guessing that's not really how projects are supposed to be used as that'd make the environment concept redundant.

Another option a colleague suggested was to create the projects in terraform but add the ignore_changes lifecycle argument e.g.

  lifecycle {
    ignore_changes = [
      environments,
    ]
  }

In either case the implementation just feels clunky. To me it seems perfectly reasonable to allow a project to exist without any environments, just the same way as you could have a security group in AWS without any rules. Conceptually, a project itself is nothing more than a container with zero or more environments and although one could argue that it doesn't make sense to have a project without any envs, clearly that would be helpful to allow more modular configuration and prevent the issues we're discussing.

[sloloris]

Hi @antonosmond,

Sorry for the late response! This slipped my radar somehow.

I do understand what you're saying and I agree that it is rather clunky - it was a very difficult design decision when updating our provider. Unfortunately, the default environments are built into our APIs already and it would be very difficult to roll out a new version. That said, I will pass along your feedback to the team that manages this.

Have a great rest of your week!

[mritterfigma]

Just for posterity, my team has the exact same use case. We spin up an arbitrary number of environments, and each one should have a corresponding LaunchDarkly environment. We cannot know all of the environments at the time when we declare the Terraform project, so we cannot include them as a list there.

Our current workaround is to simply leave the project outside of terraform and accept the loss of IaC. We could do even better with the ignore_changes property. But it would be really cool if the two could be separated.

Maybe if there is a LaunchDarkly v3 API, it would support creating a project without also creating environments. I think this is the fundamental problem, since creating child resources as a side effect of creating a given resource is not RESTful.