Issue importing project with environments

[klubi]

Hi

Not sure if this is an issue on terraform side, or rather on LaunchDarkly API end.

We're using Launch Darkly for few years, and finally we're looking into importing our setup to terraform.
Unfortunately import behaves in a very strange way, which will make it difficult to manage in the future.

Looks like terraform import does not sort imported environments in alphabetical order (by key).

I'm creating a module to manage our setup. I have few projects with few environments, so in terraform I use for_each to iterate over several collections. Since terraform maps are sorted by key name this makes it difficult to manage.
It's also weird that I'd have to re-order by collections to match what is state.

[darrenkidd]

I'm seeing the same issue (I think).

projects.tf

resource "launchdarkly_project" "test" {
  key  = "test-project"
  name = "Some Test Project"
  tags = []

  environments {
    key   = "test"
    name  = "Test"
    color = "F5A623"
    tags  = []
  }

  environments {
    key   = "uat"
    name  = "UAT"
    color = "ff0048"
    tags  = []
  }

  environments {
    key   = "production"
    name  = "Production"
    color = "417505"
    tags  = []
  }
}

So here, we are just ordering arbitrarily as TEST/UAT/PROD.

So, I've imported using terraform import and now do a terraform plan:

$ terraform-1.1.7 plan

launchdarkly_project.test: Refreshing state... [id=test-project]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the
following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # launchdarkly_project.test will be updated in-place
  ~ resource "launchdarkly_project" "test" {
        id                 = "test-project"
        name               = "Some Test Project"
        tags               = []
        # (2 unchanged attributes hidden)

      ~ environments {
          ~ color                = "ff0048" -> "F5A623"
          ~ key                  = "uat" -> "test"
          ~ name                 = "UAT" -> "Test"
            tags                 = []
            # (8 unchanged attributes hidden)

            # (1 unchanged block hidden)
        }
      ~ environments {
          ~ color                = "F5A623" -> "ff0048"
          ~ key                  = "test" -> "uat"
          ~ name                 = "Test" -> "UAT"
            tags                 = []
            # (8 unchanged attributes hidden)

            # (1 unchanged block hidden)
        }
        # (2 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if
you run "terraform apply" now.

The proposed changes are exactly the same in terms of content, but as the order has changed it shows updates everywhere (TEST and UAT have swapped).

I had a good look at the LaunchDarkly API can couldn't see anything in the project config which relates to ordering, so I feel that Terraform shouldn't care about the order either.

[klubi]

Yes @darrenkidd, this is exactly my issue! Thanks for adding outputs!

[sloloris]

Hi @klubi @darrenkidd,

Thanks for bringing this to our attention. This is a known limitation of Terraform with no optimal solution at this time, but if you're interested, I can give a bit of background as to what is happening here:

The Terraform configuration language has its own types for resource attributes. When we were designing the project resource, we considered both a TF TypeSet and a TypeList for the environments attribute; we ultimately went with a TypeList because, if you wish to refer to the attribute elsewhere in your Terraform configuration code, you can do so with a simple index, for example launchdarkly_project.test.environments.0.key. With a TypeSet, you need an unknown set hashkey to reference a specific element in the set, rendering this particular - and, in our opinion, important - functionality moot.

However, the downside of the TypeList type is that it is, of course, ordered. What has happened here is that Terraform has imported the project into the state after all the required attributes were defined in your code, but not actually cross-compared it against the configuration code itself until you ran a plan. Then, when you run the first plan, if you have not put the environments in the resource configuration in the same order it was imported into the state (which is, of course, variable, because it is unordered in our API), then you see a diff due to the expected order change.

However, due to similar concerns customers have raised in the past, we have ensured that this diff, although confusing, will not actually change your environments in LaunchDarkly - all SDK keys will remain the same. It is simply a diff between your config pre-first apply and the state. All subsequent applies should be fine once the state has been reordered to match your configuration.

We apologize for any confusion this may cause, and realize that this is not an ideal behavior. We spent a lot of time researching and looking at other major providers to decide what course to take when choosing this behavior, and this seems to be a common approach as well as a known limitation (and frustration) with the Terraform provider SDK.

Hope that helps!

[darrenkidd]

Thanks @sloloris for that explanation - makes sense. I think you've navigated the best possible solution given the circumstances.

Is there potentially some documentation we can sprinkle somewhere to notify devs of this? So that we don't have others raising the same issue?