New resource: tfe_workspace_variable_set

[brandonc]

Description

Adds resource to add workspaces to variables sets instead of managing all workspace ids in the variable set resource. This is based on #526, with the following differences:

1. Renames the resource to be more conventional with the other resource names, such as tfe_workspace_run_task
2. Implements a custom importer so that varsets can be imported by organization/workspace/varset names instead of id's
3. Adds deprecation warning for tfe_variable_set field workspace_ids and migrates examples to the new resource.

Closes: #467

Testing plan

You can use the config in the website documentation as a starter config. Here are some configs I tested with:

Basic config

resource "tfe_organization" "foobar" {
  name  = "test-varsets"
  email = "bcroft@hashicorp.com"
}

resource "tfe_workspace" "foobar" {
  name         = "test-varsets"
  organization = tfe_organization.foobar.id
}

resource "tfe_variable_set" "test" {
  name          = "Test Varset"
  description   = "Some description."
  organization  = tfe_organization.foobar.name
}

resource "tfe_variable" "test" {
  key             = "A_VARIABLE"
  value           = "value!"
  category        = "env"
  description     = "an environment variable"
  variable_set_id = tfe_variable_set.test.id
}

resource "tfe_workspace_variable_set" "foobar" {
  workspace_id      = resource.tfe_workspace.foobar.id
  variable_set_id   = resource.tfe_variable_set.test.id
}

Using for_each to apply varsets to tagged workspaces

1. Create some workspaces, some tagged "prod" 2. Apply this config, changing the organization name

data "tfe_workspace_ids" "prod-apps" {
  tag_names    = ["prod"]
  organization = "brandonc"
}

resource "tfe_variable_set" "test" {
  name          = "Tag Based Varset"
  description   = "Variable set applied to workspaces based on tag."
  organization  = "brandonc"
  global        = true
}

resource "tfe_workspace_variable_set" "test" {
  for_each        = toset(values(data.tfe_workspace_ids.prod-apps.ids))
  workspace_id    = each.key
  variable_set_id = tfe_variable_set.test.id
}

Also try importing using ORGANIZATION/WORKSPACE NAME/VARSET NAME import id

Output from acceptance tests

$ TESTARGS="-run TestAccTFEWorkspaceVariableSet" make testacc
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test $(go list ./... |grep -v 'vendor') -v -run TestAccTFEWorkspaceVariableSet -timeout 15m
?   	github.com/hashicorp/terraform-provider-tfe	[no test files]
=== RUN   TestAccTFEWorkspaceVariableSet_basic
--- PASS: TestAccTFEWorkspaceVariableSet_basic (61.20s)
PASS
ok  	github.com/hashicorp/terraform-provider-tfe/tfe	61.757s
?   	github.com/hashicorp/terraform-provider-tfe/version	[no test files]
...

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1202484608087496

[rexredinger]

This is awesome!!!

[nfagerlund]

Gonna road-test this real quick.

[brandonc]

Doc Previews:

[nfagerlund]

Caught one straightforward bug with import, and there's that weirdness with the deprecation warning.

And then there's one other thing, which I couldn't chase down to a root cause before quitting time.

1. Say you follow the examples where you have:
   • One varset resource with no workspace_ids declared.
   • A for_each'd tfe_workspace_variable_set working from a set of workspace IDs.
2. You apply once, everything's in a stable state.
3. You remove one workspace ID from the set and apply again.
   • Works as expected, deleting the attachment.
4. You do nothing, and apply again.
   • Whoa, it detects drift in the state of the varset resource's workspace_ids! The state recorded the varset's workspace_ids as including the ID you removed from the attachment resource, which no longer exists in the real infrastructure (as expected, because the apply removed it!).
5. If you apply again, you can see the drift is now resolved.

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply":

  # tfe_variable_set.fail has changed
  ~ resource "tfe_variable_set" "fail" {
        id            = "varset-HcoqnodMamWSuLvw"
        name          = "failure"
      ~ workspace_ids = [
          - "ws-Go49bka15DGPyE4b",
            # (1 unchanged element hidden)
        ]
        # (2 unchanged attributes hidden)
    }


Unless you have made equivalent changes to your configuration, or ignored the relevant attributes using ignore_changes,
the following plan may include actions to undo or respond to these changes.

I'm not sure what to do about that. Strip the workspace_ids out of the state if that argument isn't set? Hmm.

Anyway, see ya Monday.

[nfagerlund]

?? Seems unrelated, though I guess I'm not against it.

[brandonc]

It is. This just looked like developer logging

[nfagerlund]

I cannot for the life of me get this deprecation warning to fire when I have workspace_ids set, even by setting TF_LOG=info or whatever. Any thoughts?

[brandonc]

I could not, either, unless I changed the log to say [DEBUG] and set TF_LOG_PROVIDER to DEBUG. I think there must be something wrong with the WARN log level in either the SDK or terraform itself!

--
2022-06-27T10:56:06.615-0600 [DEBUG] provider.terraform-provider-tfe: 2022/06/27 10:56:06 [WARN] Truncating attribute path of 0 diagnostics for TypeSet
2022-06-27T10:56:06.978-0600 [DEBUG] provider.terraform-provider-tfe: 2022/06/27 10:56:06 [DEBUG] Apply variable set Test Varset to workspaces &{0x16cc000 map[3773104766:ws-sdUGzEWvMSs35Rwq] {1 {0 0}}}
2022-06-27T10:56:06.978-0600 [DEBUG] provider.terraform-provider-tfe: 2022/06/27 10:56:06 [DEBUG] The workspace_ids field of tfe_variable_set is deprecated as of release 0.33.0 and may be removed in a future version. The preferred method of associating a variable set to a workspace is by using the tfe_workspace_variable_set resource.
2022-06-27T10:56:07.571-0600 [DEBUG] provider.terraform-provider-tfe: 2022/06/27 10:56:07 [DEBUG] Read configuration of variable set: varset-cMjkscyw39QNSDmW
2022-06-27T10:56:08.332-0600 [DEBUG] provider.terraform-provider-tfe: 2022/06/27 10:56:08 [DEBUG] Create env variable: A_VARIABLE

The question is, do we change this to a DEBUG log or keep it WARN and go looking for the fix upstream?

[brandonc]

@nfagerlund maybe we should go with WARN and migrate from log.Print to tflog before the next release.

[nfagerlund]

OK, cool, I think I like that idea. Weird that we haven't run into this WARN issue before???

[brandonc]

There are no other warn logs in this repo!

[nfagerlund]

We went back to figure out why one of us could repro that drift reporting problem and the other couldn't, and it turned out I was running an old 1.1.x dev version of Terraform and the spurious drift reporting doesn't happen in Terraform 1.2. 🤦 So that was a Terraform bug, and it's fixed. Twist ending!!

With that, I'm feeling good about this PR.