cloud: Allows object tag schema for selecting key/value tagged workspaces

[brandonc]

When key-value tags are enabled and used in the workspace, users may define the tags attribute as a map of strings in the cloud block in order to more precisely match workspaces using those tags.

Target Release

1.10.x

Draft CHANGELOG entry

ENHANCEMENTS

• cloud block workspace tag attribute can now be defined as either a set(string) (matching key only) or a map(string) (matching keys and values together)

Example output: init cloud block with kv tags

$ ./terraform init
Initializing HCP Terraform...

No workspaces found.

  There are no workspaces with the configured tags (cc=101, dept=billing)
  in your HCP Terraform organization. To finish initializing, Terraform needs at
  least one workspace available.

  Terraform can create a properly tagged workspace for you now. Please enter a
  name to create a new HCP Terraform workspace.

  Enter a value:

[Maed223]

From smoke testing I'm seeing a couple problems

In using the old single value tags:

Cloud Block:

cloud {
    hostname     = "app.staging.terraform.io"
    organization = "markdecrane"
    workspaces {
      tags = ["app", "test"]
    }
  }

Error:

Besides the fact that this is occuring, it seems odd to me that the errors Error: failed to create backend alias to target "". The hostname is not in the correct format. and Error: Invalid workspaces configuration are given when an incorrect type for tags is given. Saw nearly the same diags on the console when giving tags the value of a single string.

Nil panics when the value of of tag is not a string

I'm also seeing a need for some more error handling as I get nil panics when the value of of tag is not a string:

Weirdly not a problem when the key itself is not a string

workspaces {
      tags = {
        1 = "foo"
        2 = "bar"
      }
    }

Looks as though it's somehow treated as a string considering it doesn't break things at any point in the workflow, despite this error message I came across when specifying the key as a set, dictating that the key must be a string:

[brandonc]

@Maed223 thanks for the thorough testing! There was an interesting mismatch between the existing tests and the actual type that happens when you write config (Set vs Tuple) which broke the legacy use cases! Glad we caught that.

I also detected and fixed the case when element types were not strings. In the case of keys not being strings, that's built into the syntax of the language (all object/map keys are strings). For instance, you can define an object like { hello = "world" }

[Maed223]

A couple more behavioral oddities I detected, one of which might be on the atlas API side of things but I'll note here.

Single-Value-Tag/ KV-Tag matching

Saw that choosing a workspace when single value tags (in config) are matched to the key values of KV tags (on the workspace) there's a duplication of the tags– in that the KV tags that are being matched to are persisted and additional single value legacy tags are created on the workspace.

For example:

workspaces {
  tags = ["app", "test"]
}

Also saw that the inverse of this occurs as well. As in KV tags in config matching to single value tags on a workspace persists the single value tags, while adding the new KV tags.

Wondering what the intention is for the behavior here. I can see the value in adding the KV tags when the workspace only has the single value tags considering the KV tags hold more info (but should the original legacy tags persist?), but less so for the inverse case. No strong opinion here, just saw that this aspect wasn't specifically discussed in the RFC.

Extraneous error message when giving incorrect type to value of KV tag

Less than before, but still seeing the error related to the hostname when giving a non-string value as a KV tag's value. Not breaking, but feels less than ideal.

[brandonc]

@Maed223 These are interesting questions and yes, a mismatch between how workspaces are found vs how "workspaceTagsRequireUpdate" detects. I do think I want to refine the behavior, but since the beta is getting cut tomorrow, do you mind if we merge it in this state and refine it during the beta period?

I'll look into the alias error as well, but I think that is unrelated to the change.

[github-actions]

Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.