We're starting to see HTTP 429 Too many requests on TFE intermittently, which then breaks the run. The provider should back off gracefully and retry when this happens.

Running from within Terraform Cloud, if that is relevant.

Currently, I'm having to find the Oauth Token ID outside of Terraform. It would be very helpful if this could be part of the Terraform workflow.

Having a Data Source that looks this up would solve the problem.

Something around this api endpoint, to allow adding new/custom versions of Terraform.

Hi,

Would be great if we are able to attach a policy set to workspace instead of attach workspace to policy set; example:

resource "tfe_workspace_sentinel_attach" "this" {
policy_set_id = ""
workspace_id = ""
}

Thanks

I am using the TFE provider to update the terraform_version on about 50 workspaces at the same time. When I terraform apply only about 5-12 workspaces will be updated, the rest will fail with a mysterious error message saying the repository doesn't exist or isn't accessible:

[1m[31mError: [0m[0m[1mError updating workspace dotnet-services-agentmapping-peg for organization Velocify: Invalid Attribute
Repository doesn’t exist or isn’t accessible[0m

This error message doesn't seem to be a permissions issue, however. When I apply again, another 5-12 workspaces will be updated before I get the same error message. It seems to be a problem with performing too many updates at the same time, causing some of the reads to fail. There should be retry logic in the tfe_workspace resource to catch this specific error and retry at least a few times. Currently I have to apply my workspace around 5-10 times before the deployment succeeds.

I don't see a way to associate a (pre-existing) TFE ssh key with a TFE workspace - is this not-yet-implemented, or am I missing something?

Hello -

I was testing some changes and the tfe provider seems to be unhappy with code that works perfectly well under v0.6.0. It looks like the request either didn't get data back from the call or the data we did get didn't fulfill the required interface: panic: interface conversion: interface {} is nil, not map[string]interface {}.

I've pinned the provider to 0.6.0 to remediate for time time being and the code works.

Terraform/0.11.11 TFE/bf86e8a

Example code:

provider "tfe" {
  # XXX version 0.7.0 is downloaded
  version = "~> 0.6"
  token = "${var.tfe_org_token}"
}

data "tfe_team" "pso" {
  name         = "${local.pso_team_name}"
  organization = "${local.tfe_organization}"
}

Example error:

Error: Error refreshing state: 2 error(s) occurred:

* tfe_workspace.stack: 1 error(s) occurred:

* tfe_workspace.stack: tfe_workspace.stack: unexpected EOF
* data.tfe_team.pso: 1 error(s) occurred:

* data.tfe_team.pso: data.tfe_team.pso: unexpected EOF


panic: interface conversion: interface {} is nil, not map[string]interface {}
2019-02-14T22:22:00.546Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4: 
2019-02-14T22:22:00.546Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4: goroutine 58 [running]:
2019-02-14T22:22:00.546Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4: github.com/terraform-providers/terraform-provider-tfe/tfe.resourceTFEWorkspaceRead(0xc000362a10, 0xdda820, 0xc000001680, 0xc000362a10, 0x0)
2019-02-14T22:22:00.546Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4:       /opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/terraform-providers/terraform-provider-tfe/tfe/resource_tfe_workspace.go:249 +0xf4d
2019-02-14T22:22:00.547Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4: github.com/terraform-providers/terraform-provider-tfe/vendor/github.com/hashicorp/terraform/helper/schema.(*Resource).Refresh(0xc00033f880, 0xc0004afd10, 0xdda820, 0xc000001680, 0xc0002dfd28, 0x4c1b01, 0xd29960)
2019-02-14T22:22:00.547Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4:       /opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/terraform-providers/terraform-provider-tfe/vendor/github.com/hashicorp/terraform/helper/schema/resource.go:352 +0x160
2019-02-14T22:22:00.547Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4: github.com/terraform-providers/terraform-provider-tfe/vendor/github.com/hashicorp/terraform/helper/schema.(*Provider).Refresh(0xc00033f960, 0xc0004afcc0, 0xc0004afd10, 0xc0000fe700, 0x18, 0x7efe66e11000)
2019-02-14T22:22:00.547Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4:       /opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/terraform-providers/terraform-provider-tfe/vendor/github.com/hashicorp/terraform/helper/schema/provider.go:308 +0x92
2019-02-14T22:22:00.547Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4: github.com/terraform-providers/terraform-provider-tfe/vendor/github.com/hashicorp/terraform/plugin.(*ResourceProviderServer).Refresh(0xc0003216c0, 0xc00048ce50, 0xc00048d090, 0x0, 0x0)
2019-02-14T22:22:00.547Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4:       /opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/terraform-providers/terraform-provider-tfe/vendor/github.com/hashicorp/terraform/plugin/resource_provider.go:549 +0x4e
2019-02-14T22:22:00.547Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4: reflect.Value.call(0xc0002e69c0, 0xc00000d860, 0x13, 0xed6f4d, 0x4, 0xc000095f18, 0x3, 0x3, 0xc0001896c0, 0x0, ...)
2019-02-14T22:22:00.547Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4:       /opt/goenv/versions/1.11.4/src/reflect/value.go:447 +0x454
2019-02-14T22:22:00.547Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4: reflect.Value.Call(0xc0002e69c0, 0xc00000d860, 0x13, 0xc00049e718, 0x3, 0x3, 0xc000189fc0, 0xc0000320a0, 0x722574)
2019-02-14T22:22:00.547Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4:       /opt/goenv/versions/1.11.4/src/reflect/value.go:308 +0xa4
2019-02-14T22:22:00.547Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4: net/rpc.(*service).call(0xc000345d80, 0xc000319360, 0xc00034e278, 0xc00034e290, 0xc0000c1e80, 0xc0003217a0, 0xd29920, 0xc00048ce50, 0x16, 0xd29960, ...)
2019-02-14T22:22:00.547Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4:       /opt/goenv/versions/1.11.4/src/net/rpc/server.go:384 +0x14e
2019-02-14T22:22:00.548Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4: created by net/rpc.(*Server).ServeCodec
2019-02-14T22:22:00.548Z [DEBUG] plugin.terraform-provider-tfe_v0.7.0_x4:       /opt/goenv/versions/1.11.4/src/net/rpc/server.go:481 +0x47e
2019-02-14T22:22:00.549Z [DEBUG] plugin: plugin process exited: path=/terraform/.terraform/plugins/linux_amd64/terraform-provider-tfe_v0.7.0_x4
2019/02/14 22:22:00 [ERROR] root: eval: *terraform.EvalRefresh, err: tfe_workspace.stack: unexpected EOF
2019/02/14 22:22:00 [ERROR] root: eval: *terraform.EvalSequence, err: tfe_workspace.stack: unexpected EOF
2019/02/14 22:22:00 [TRACE] [walkRefresh] Exiting eval tree: tfe_workspace.stack
2019/02/14 22:22:00 [TRACE] dag/walk: upstream errored, not walking "tfe_variable.region"
2019/02/14 22:22:00 [ERROR] root: eval: *terraform.EvalReadDataApply, err: data.tfe_team.pso: unexpected EOF
2019/02/14 22:22:00 [ERROR] root: eval: *terraform.EvalSequence, err: data.tfe_team.pso: unexpected EOF
2019/02/14 22:22:00 [TRACE] [walkRefresh] Exiting eval tree: data.tfe_team.pso
2019/02/14 22:22:00 [TRACE] dag/walk: upstream errored, not walking "tfe_team_access.pso_read"
2019/02/14 22:22:00 [TRACE] dag/walk: upstream errored, not walking "tfe_variable.credentials"
2019/02/14 22:22:00 [TRACE] dag/walk: upstream errored, not walking "tfe_variable.secret_foo"
2019/02/14 22:22:00 [TRACE] dag/walk: upstream errored, not walking "tfe_variable.secret_baz"
2019/02/14 22:22:00 [TRACE] dag/walk: upstream errored, not walking "tfe_variable.cluster_name"
2019/02/14 22:22:00 [TRACE] dag/walk: upstream errored, not walking "tfe_team_access.phoogle_write"
2019/02/14 22:22:00 [TRACE] dag/walk: upstream errored, not walking "tfe_variable.secret_bar"
2019/02/14 22:22:00 [TRACE] dag/walk: upstream errored, not walking "tfe_variable.project"
2019/02/14 22:22:00 [TRACE] dag/walk: upstream errored, not walking "tfe_variable.workspace_owner"
2019/02/14 22:22:00 [TRACE] dag/walk: upstream errored, not walking "provider.tfe (close)"
2019/02/14 22:22:00 [DEBUG] plugin: waiting for all plugin processes to complete...
2019-02-14T22:22:00.552Z [WARN ] plugin: error closing client during Kill: err="connection is shut down"



!!!!!!!!!!!!!!!!!!!!!!!!!!! TERRAFORM CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!

Terraform crashed! This is always indicative of a bug within Terraform.
A crash log has been placed at "crash.log" relative to your current
working directory. It would be immensely helpful if you could please
report the crash with Terraform[1] so that we can fix this.

When reporting bugs, please include your terraform version. That
information is available on the first line of crash.log. You can also
get it by running 'terraform --version' on the command line.

[1]: https://github.com/hashicorp/terraform/issues

!!!!!!!!!!!!!!!!!!!!!!!!!!! TERRAFORM CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!

tfe_policy_set can create vcs_repo configuration but it's not able to make changes. Plan shows changes to be made and apply says it changed resources but running plan again shows changes were not applied.

How to reproduce:
First create policy set:

resource "tfe_policy_set" "foo" {
  name = "foo"
  vcs_repo {
    identifier = "github-repo"
    oauth_token_id = "token-id"
  }
}

Next update let's add ingress_submodules attribute:

resource "tfe_policy_set" "foo" {
  name = "foo"
  vcs_repo {
    identifier = "github-repo"
    ingress_submodules = true
    oauth_token_id = "token-id"
  }
}

Possible solution:
I don't see anywhere in update section of the code to check vcs_repo changes. There is for Create and Read but for Update is missing.
https://github.com/terraform-providers/terraform-provider-tfe/blob/master/tfe/resource_tfe_policy_set.go#L227

It's great that tfe_oauth_client supports personal access tokens for helping configure the VCS settings in Orgs and for Repos in TF Cloud / pTFE, however it would be better if we could also support the Apps or OAuth Apps side for GHE/GH so that we can relieve personal access tokens from the workflow of plans/applies/etc.

Ex.

resource "tfe_oauth_client" "test" {
  organization     = "my-org-name"
  api_url          = "https://github.myorg.com/api/v3"
  http_url         = "https://github.myorg.com"
  oauth_token      = "my-vcs-provider-token"
  service_provider = "github_enterprise"
}

Would be great if that supported the app fields of like client_id and client_secret and populated the callback_url on the GH/GHE side. This would allow ORGs to own tokens and not individuals

Trying to create a tfe_variable resource with a value of list gives: Error tfe_variable.availability_zones: value must be a single value, not a list

Latest .11.10

resource "tfe_variable" "availability_zones" {
hcl = true
key = "availability_zones"
value = ["us-east-1a","us-east-1b","us-east-1c"]
category = "terraform"
workspace_id = "${tfe_workspace.nc_use1_inf_dev_net.id}"
}
I've tried re-writing the value with various quote methodologies. Am I doing something wrong or is this not handled by provider?

Hi, It would be great if the provider was able to source the TFE token via the same mechanisms that Terraform can use, specifically the credentials_helper in your .terraformrc file. This would help when testing local-apply and remote-state-only Terraform runs.

An example of how to setup a credential helper is linked in this Gist

Terraform Credential Helper Gist

With the release of the notifications feature for TFE on 3/1, and the corresponding Notification Configurations API, it’d be nice to see that added as a resource in the TFE provider.

I may endeavor to do this myself, but I thought I’d add a ‘feature request’ here in the Issues tracker in case anyone else is considering doing the same work.

TFE introduced concept of teams which have special access in an organizations, which can:

1. Manage policies
2. Manage workspaces
3. Manage VCS connection

Add these features to TFE provider tfe_team resource

See: https://www.terraform.io/docs/enterprise/api/teams.html

Right now, the ID given for a workspace from Terraform is org-name|workspace-name

However, if you want to use the API to do something, like trigger a run or such, you have to use the workspace ID as defined by the TFE API, which is an alphanumeric like ws-oMQsEub2cEKmPBAs:

{
  "data": {
    "id": "ws-mD5bmJ8ry3uTzuHi", #this bit
    "type": "workspaces",
    "attributes": {
      "name": "workspace-1",
      "environment": "default",
      "auto-apply": false,
      "locked": false,
      "created-at": "2018-03-08T22:30:00.404Z",
      "working-directory": null,
      "terraform-version": "0.11.3",
      "permissions": {
        "can-update": true,
        "can-destroy": true,
        "can-queue-destroy": true,
        "can-queue-run": true,
        "can-update-variable": true,
        "can-lock": true,
        "can-read-settings": true
      },
      "actions": {
        "is-destroyable": true
      }
    },

It would be good to have this as a read-only varible for resources, so it can be output on creation so it can be used outside of Terraform

Without TFE_TOKEN:

Error: Error creating env variable AWS_ACCESS_KEY_ID: resource not found

on main.tf line 59, in resource "tfe_variable" "AWS_ACCESS_KEY_ID":
59: resource "tfe_variable" "AWS_ACCESS_KEY_ID" {

With tfe token:

AWS_ACCESS_KEY_ID: Creating...
AWS_ACCESS_KEY_ID: Creation complete after 1s [id=var-s5WHTKna5g3m81qd]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

3 different issues here.

1. Using the terraform_remote_state data source with a "remote" backend and setting the workspace block results in the error "Error: data.terraform_remote_state.producer: config (workspaces): '' expected type 'string', got unconvertible type '[]map[string]interface {}'" - I believe I'm setting it appropriately (below), but no dice
2. When manipulating the workspace block trying to get it to work, it will cause Terraform to crash (either removing the workspace block completely or entering values that Terraform doesn't expect)
3. Setting the terraform remote backend block and running a plan in TFE results in the error "Setup failed: Failed to copy slug dir: lstat /Users: no such file or directory"

Terraform Version

Terraform v0.11.8
+ provider.aws v1.33.0
+ provider.vault v1.1.1

Terraform Configuration Files

https://gist.github.com/bensojona/962220df94b3681731d9814c4a2d3060

You can comment out the consumer_workspace module if trying to reproduce, it's irrelevant to the error.

variable "tfe_org_name"           { }
variable "tfe_producer_workspace" { }
variable "tfe_consumer_workspace" { }
variable "tfe_consumer_token"     { }
variable "ttl"                    { default = "1" }

/*
# Getting the below error in TFE when running remote plans, commenting this out for now
# "Setup failed: Failed to copy slug dir: lstat /Users: no such file or directory"
terraform {
  backend "remote" {
  }
}
*/

data "terraform_remote_state" "producer" {
  backend = "remote"

  config {
    organization = "${var.tfe_org_name}"
    token        = "${var.tfe_consumer_token}"

    workspaces {
      name = "${var.tfe_producer_workspace}"
    }
  }
}

module "consumer_workspace" {
  # source = "github.com/hashicorp/terraform-guides//infrastructure-as-code/dynamic-aws-creds/consumer-workspace"
  source = "../../dynamic-aws-creds/consumer-workspace"

  backend = "${data.terraform_remote_state.producer.backend}"
  role    = "${data.terraform_remote_state.producer.role}"
  name    = "${var.tfe_consumer_workspace}"
  ttl     = "${var.ttl}"
}

Debug Output

https://gist.github.com/bensojona/2d474b421e35c6ae87451963e28771e2

Crash Output

This crash is from attempting to manipulate the workspace block in terraform_remote_state or removing it completely, which is separate from the terraform plan error I get with the above config - but still an issue.

https://gist.github.com/bensojona/769c79c6ecae0bf23e86817c17e3a34c

Expected Behavior

terraform_remote_state data source should have pulled remote state from workspace. I should also be able to enter incorrect workspace block config with a proper error vs. crashing.

Actual Behavior

Errors with Error: data.terraform_remote_state.producer: config (workspaces): '' expected type 'string', got unconvertible type '[]map[string]interface {}'.

Or a crash if manipulating the workspace block.

Steps to Reproduce

1. terraform init
2. terraform plan

It would be great if we can support the creation of parameters for a Sentinel Policy via the TFE provider.

This seems to be now support in Terraform Enterprise On-Prem (though I am not sure if Terraform Cloud has this yet).

Currently, we need to do this through the UI but it would be great if we can define this in code so that it can go through the normal code review and TF pipeline.

The line on the tfe_policy_set resource documentation [1] for workspace_external_ids trails off:

workspace_external_ids - (Optional) A list of workspace external IDs. If

If ... what? -- shakes monitor.
[1]: https://www.terraform.io/docs/providers/tfe/r/policy_set.html#workspace_external_ids

I was having issues setting up TFE with the provider, only realised what the issue was when I did a debug

2018/09/14 15:25:03 [2018-09-14T15:25:03.909+0100 [DEBUG] plugin.terraform-provider-tfe_v0.1.0_x4: 2018/09/14 15:25:03 [DEBUG] Service discovery for ptfe.petems.xyz at https://ptfe.petems.xyz/.well-known/terraform.json
2018-09-14T15:25:04.323+0100 [DEBUG] plugin.terraform-provider-tfe_v0.1.0_x4: 2018/09/14 15:25:04 [WARN] Failed to request discovery document: Get https://ptfe.petems.xyz/.well-known/terraform.json: x509: certificate signed by unknown authority

certificate signed by unknown authority would be a nicer error to show, rather than provider.tfe: host ptfe.petems.xyz does not provide a Terraform Enterprise API

Since we are getting deprecation warnings for v0.11.x, we should already have TFE also using the newer 0.12 syntax.

TL;DR: Engineers often read the underlying API docs to understand the expected input that may otherwise be causing Terraform to fail cryptically. Renaming the human readable API objects in terraform HCL attributes creates vast confusion. Consider remapping all attribute names & IDs directly to their API counter parts, or choose a standard mapping scheme and stick with it.

ISSUE:

• tfe_variable Importing: When attempting to import a TFE variable, terraform will return successful, but then subsequently fail when attempting to read the value. Importing using the API's id, will return successful. The TFE variable API id isn't visible in the UI, and doesn't match the scheme of the workspace..id, so it's not at all intuitive for a user.

# fails
terraform import tfe_variable.test <org>/<workspace name>/<var name>
# passes
terraform import tfe_variable.test <org>/<workspace name>/<var id from API>

• tfe_variable Creating: tfe_variable workspace_id perpetuates this confusion by requiring workspace_id, but this isn't the API's id for the workspace, instead this is expecting something like .relationships.organization.data.id / .attributes.name

# fails
workspace_id = "ws-abcdefghijkl"
# works
workspace_id = "<org_name>/<workspace_name>" # ie tfe_workspace..id

• ID mismatch; tfe_variable..id vs tfe_workspace..id: tfe_variable returns the API ID, where as the tfe_workspace returns .relationships.organization.data.id / .attributes.name which seems to lack consistance, and isn't strait forward for the user.

• name and ID's are used interchangeably in documentation, leading to confusion that breaks external wrapper use if you actually want the name or ID (one may be missing today on some resources).

tfe_organization..id "The name of the organization."
vs
tfe_variable..id "The ID of the variable."

tfe_workspace..external_id = ws-abcdefghijkl
vs
tfe_workspace..id = <org>/<workspace_name>

Recommendation:
Introduce a breaking change now in version 0.3.0 of the TFE provider. Add name and id attributes for all resources, and map directly to the API's JSON objects with the same element names.

name = name
id = id

Update tfe_variable to track the human readable <org name>/<workspace name>/<key name> (instead of the hidden id value: <org name>/<workspace name>/<key id>)

I am wanting to use Terraform/TFE to manage Policies and Policy Sets for a TFE organisation.

When I try to create a policy the terraform plan indicates that the policy will be created, however when the apply runs, i get an error:

Error: Error creating sentinel policy always-pass for organization gcp-policy-test: resource not found

The resource code is:

resource "tfe_sentinel_policy" "always_pass" {
  name         = "always-pass"
  description  = "This policy always passes"
  organization = "gcp-policy-test"
  policy       = "main = rule { true }"
  enforce_mode = "advisory"
}

The full output of the remote execution is:

terraform apply
Running apply in the remote backend. Output will stream here. Pressing Ctrl-C
will cancel the remote apply if it's still pending. If the apply started it
will stop streaming the logs, but will not stop the apply running remotely.

Preparing the remote apply...

To view this run in a browser, visit:
https://terraform.<private.url>/app/policy-test/TFE-Test-policy/runs/run-HhotRkKq2MFXD6do

Waiting for the plan to start...

Terraform v0.12.16
Configuring remote state backend...
Initializing Terraform configuration...
2020/01/28 01:01:55 [DEBUG] Using modified User-Agent: Terraform/0.12.16 PTFE/b5916fe
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.


------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # tfe_sentinel_policy.always_pass will be created
  + resource "tfe_sentinel_policy" "always_pass" {
      + description  = "This policy always passes"
      + enforce_mode = "advisory"
      + id           = (known after apply)
      + name         = "always-pass"
      + organization = "policy-test"
      + policy       = "main = rule { true }"
    }

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

Do you want to perform these actions in workspace "TFE-Test-policy"?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

tfe_sentinel_policy.always_pass: Creating...

Error: Error creating sentinel policy always-pass for organization policy-test: resource not found

  on policy_resource.tf line 1, in resource "tfe_sentinel_policy" "always_pass":
   1: resource "tfe_sentinel_policy" "always_pass" {

I was hoping to use the same folder structure and sentinel.hcl file as indicated for the VCS integration, but create/manage through terraform code specifically instead of VCS integration.

Regards

Allan

I've discovered an issue where renaming a workspace, via a variable map, causes an error on terraform apply, that is fixed by running a second apply.

Terraform Version

TFC via Terraform 0.12.20

Terraform Configuration Files

The TLDR of this config is that I'm provisioning/managing a TFC org and the associated workspaces, using for_each to populate the AWS creds for each workspace.

provider "tfe" {
  hostname = "app.terraform.io"
}

variable "my_aws_key_id" {
  type        = string
  description = "AWS Access key id"
}

variable "my_aws_access_key" {
  type        = string
  description = "AWS key"
}

variable "workspaces" {
  type = map
  default = {
    tfc_config  = "TFC_Config"
    zones       = "Route53_Zones"
    certs       = "Certificates"
    A_domains   = "Domains_Project_A"
    A_resources = "Resources_Project_A"
    B_domains   = "Domains_Project_B"
    B_resources = "Resources_Project_B"
    C_domains   = "Domains_Project_C"
    C_resources = "Resources_Project_C"
  }
}

resource "tfe_organization" "my-org" {
  name  = "org"
  email = "[email protected]"
  lifecycle {
    prevent_destroy = true
  }
}

resource "tfe_workspace" "my-org_workspace" {
  for_each     = var.workspaces
  name         = each.value
  organization = tfe_organization.my-org.id
  lifecycle {
    prevent_destroy = true
  }
}

resource "tfe_variable" "aws_key_id" {
  for_each     = var.workspaces
  key          = "AWS_ACCESS_KEY_ID"
  value        = var.my_aws_key_id
  category     = "env"
  workspace_id = tfe_workspace.my-org_workspace[each.key].id
}

resource "tfe_variable" "aws_key" {
  for_each     = var.workspaces
  key          = "AWS_SECRET_ACCESS_KEY"
  value        = var.my_aws_access_key
  category     = "env"
  sensitive    = true
  workspace_id = tfe_workspace.my-org_workspace[each.key].id
}

Debug Output

I didn't catch one but it's repeatably so if I must, I will return with one. ;)

Crash Output

Error: Provider produced inconsistent final plan

When expanding the plan for tfe_variable.aws_key["c_domains"] to include
new values learned so far during apply, provider "registry.terraform.io/-/tfe"
produced an invalid new value for .workspace_id: was
cty.StringVal("my_org/C_Domains"), but now
cty.StringVal("my_org/Domains_C").

This is a bug in the provider, which should be reported in the provider's own
issue tracker.


Error: Provider produced inconsistent final plan

When expanding the plan for tfe_variable.aws_key_id["b_domains"] to
include new values learned so far during apply, provider
"registry.terraform.io/-/tfe" produced an invalid new value for .workspace_id:
was cty.StringVal("my_org/B_Domains"), but now
cty.StringVal("my_org/Domains_B").

This is a bug in the provider, which should be reported in the provider's own
issue tracker..

Expected Behavior

When I change the value of a mapped variable, terraform apply should not fail.

Actual Behavior

terraform apply fails the first time with the above error. A second terraform apply works and my resources are in their expected state [pun totally intended].

Additional Context

If I were to change a var.workspaces.value from "My_Workspace" to "My_workspace" the workspace is renamed without issue during a terraform apply.

However, when I change a value of a var.workspace.value from "My_Workspace" to "Workspace_A" the two associated variables are not able to be destroyed and recreated on the first terrafrom apply. A second terraform apply is required.

Importing team does not work and I am getting an invalid team import format error, see below:

 eboumendil@C02VD27BHV2H # terraform import tfe_team.test TeWWKkK1yDNrHgoz        
                                                   
tfe_team.test: Importing from ID "TeWWKkK1yDNrHgoz"...

Error: tfe_team.test (import id: TeWWKkK1yDNrHgoz): import tfe_team.test (id: TeWWKkK1yDNrHgoz): invalid team import format: TeWWKkK1yDNrHgoz

Using tfe_workspace resource and it successfully creates the workspaces and VCS configuration:

resource "tfe_workspace" "test" {
  name              = "test"
  organization      = "my-organization"
  auto_apply        = true
  terraform_version = "0.12.7"
  working_directory = "terraform"

  vcs_repo {
    identifier     = "my-organization/my-repo"
    oauth_token_id = "********"
  }
}

everything looks fine in . TFE, but if I remove the VCS config after, Terraform detects that it needs to remove it and it applies without any error but it does not remove the VCS config and the change shows up . in every run until the VCS config manually get removed.

Terraform v0.12.7
+ provider.tfe v0.11.0```

I may be overlooking it, but the tfe_team_access resource ID (referenced in the import example for the tfe_team_access resource, here), isn't made visible through any existing TFE API endpoint. (Searching Terraform.io for 'tws-' yields only that page.) Is there some other way to retrieve this ID, or is this one of those edge cases where the id can only be gotten once the resource is in the TF state?

Thanks!
Heath

Scenario
When setting trigger_prefixes for a workspace to trigger on a specific file instead of a directory in the repository and update the file the workspace doesn't trigger an update.

Example:

resource "tfe_workspace" "workspace" {
  ...

  vcs_repo {
    ...
  }

  working_directory = "/cluster-module"

  trigger_prefixes = [
    "/cluster-config/config-for-all-clusters.yaml",
    "/cluster-config/cluster1-specific-config-folder",
  ]
}

Scenario would be to update the file /cluster-config/config-for-all-clusters.yaml in this example

Expected behaviour
The workspace trigger an update.

Actual behaviour
The workspace doesn't trigger an update.

It's not quite clear how this should work. My assumption is that it assumes you've already got a VCS connection on the org setup, but even when that's the case, I'm not sure how to configure it so it knows which VCS connection to use.

I get the below error when running a plan. Not sure if that's a bug, either way, a more descriptive error could help.

Error: Error applying plan:

1 error(s) occurred:

* tfe_workspace.producer: 1 error(s) occurred:

* tfe_workspace.producer: Error updating workspace dynamic-aws-creds-producer for organization jbenson_test: internal server error

Config looks like this..

resource "tfe_workspace" "producer" {
  name         = "${var.producer_name}"
  organization = "${tfe_organization.org.id}"
  working_directory = "${var.producer_wd}"

  vcs_repo {
    identifier = "hashicorp/terraform-guides"
    branch     = "f-dynamic-aws-creds-tfe"
    oauth_token_id = "${var.token}"
  }
}

A nice feature enhancement would be to be able to create a VCS connection on the org as a resource as well.

Hi,

I think there is a problem with the option ssh_key_id, it return:
Error: Error assigning SSH key to workspace ric-gcp-master-prd-project: resource not found
From the UI, when I the update ssh key form, the payload send with PATH method is:
{"data":{"type":"ssh-keys","id":"sshkey-BQzjZbkeiZARSkYa"}}
From Terraform:
{"data":{"type":"workspaces","attributes":{"id":"sshkey-BQzjZbkeiZARSkYa"}}}
Both requests are send to the same URL:
PATCH /api/v2/workspaces/ws-X5XHbSHEWvc5nPDf/relationships/ssh-key

Version: plugin.terraform-provider-tfe_v0.11.1_x4.exe

Thanks,

Using the example from here: https://www.terraform.io/docs/providers/tfe/r/notification_configuration.html (only disabling the ORG creation) - tf apply fails with this:

tfe_workspace.test: Creating...
tfe_workspace.test: Creation complete after 2s [id=XXXX/my-workspace-name]
tfe_notification_configuration.test: Creating...

Error: Error creating notification configuration my-test-notification-configuration: resource not found

  on main.tf line 18, in resource "tfe_notification_configuration" "test":
  18: resource "tfe_notification_configuration" "test" {

Terraform version: 0.12.7
TFE module version: 0.11.0

Should be very repeatable error...

I'm using a organization token.

I am trying to have a tf file that manages the remote variables of our workspaces. When I run this example tf file locally it works fine, if I try and run it remotely it failes with:
Error: Error creating terraform variable workspace: resource not found

here is the tf info

provider "tfe" {
  hostname = "app.terraform.io"
}

terraform {
  backend "remote" {
    hostname = "app.terraform.io"
    organization = "org"
    workspaces {
      name = "app-terraform"
    }
  }
}

locals {
  workspaces = ["app-dev-useast1", "app-dev-uswest2", "app-int-uswest2"]
}

resource "tfe_workspace" "workspaces" {
  for_each = toset(local.workspaces)

  name = each.value
  organization = "org"
  file_triggers_enabled = false
  queue_all_runs = false

}

resource "tfe_variable" "workspace" {
  for_each = tfe_workspace.workspaces

  category = "terraform"
  key = "workspace"
  value = each.value.name
  workspace_id = each.value.id
}

output "test" {
  value = tfe_workspace.workspaces
}

It would be very helpful if the process of connecting a Version Control System to a TFE Organization was made simpler and automatic through the usage of a new Terraform Resource.

Steps to reproduce

• Manually create a workspace default in https://app.terraform.io
• Add a Terraform Variable tfe_token, which contains a User Token as the secret
• Setup local ~/.terraformrc
• Create a main.tf like below
• Run terraform init
• Run terraform import tfe_workspace.default <org>/new-workspace
• Will receive an error
  • Error: Error reading configuration of workspace new-workspace: unauthorized

main.tf

terraform {
  backend "remote" {
    organization = "<org>"
    hostname     = "app.terraform.io"
    workspaces { name = "default" }
  }
}

variable "tfe_token" {}

provider "tfe" {
  token    = var.tfe_token
  hostname = "app.terraform.io"
}

resource "tfe_workspace" "default" {
  organization      = "<org>"
  name              = "new-workspace"
}

Notes

• I tried setting an environment variable TFE_TOKEN in workspace, does not work
• I hardcoded the provider with the token instead of using the variable, works fine
• I tried the token directly using curl to hit the TFE API, works fine
• This seems to be broken for other providers such as AWS as well

Is this behavior because of Terraform Cloud's sensitive "write only" secrets being unreadable when running import from my local machine? If thats the case, then there needs to be an option to run arbitrary commands like import on the remote executor.

Whats happening?

The TFE provider fails during the the plan phase with the error: host tfe.acme.internal does not provide a Terraform Enterprise API.

This occurs on Mac OSX and in the hashicorp/terraform:full docker container.

This appears to be an issue with the way Go validates certificates or the way that tfe returns the certificate chain. I'm using a Lets Encrypt certificate that's trusted in Chrome.

What Have I tried?

• Re-build the provider using go 1.10.3
• Run the provider in a linux container and on OSX

Diagnostic info

On-Prem Terraform Enterprise Version:

v201810-2

Terraform Configuration File

provider "tfe" {
  hostname = "tfe.acme.internal"
  token    = "*****"
}

terraform plan

...
2018-11-01T15:36:05.014+1100 [DEBUG] plugin.terraform-provider-tfe_v0.2.0_x4: 2018/11/01 15:36:05 [DEBUG] Service discovery for tfe.acme.internal at https://tfe.acme.internal/.well-known/terraform.json
2018-11-01T15:36:07.884+1100 [DEBUG] plugin.terraform-provider-tfe_v0.2.0_x4: 2018/11/01 15:36:07 [WARN] Failed to request discovery document: Get https://tfe.acme.internal/.well-known/terraform.json: x509: certificate signed by unknown authority
2018/11/01 15:36:07 [ERROR] root: eval: *terraform.EvalConfigProvider, err: host tfe.acme.internal does not provide a Terraform Enterprise API
...

terraform version

Terraform v0.11.10
 + provider.tfe v0.2.0

$ openssl s_client -connect tfe.acme.internal:443 -showcerts

CONNECTED(00000005)
depth=0 CN = tfe.acme.internal
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = tfe.acme.internal
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/CN=tfe.acme.internal
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
**removed for brevity**
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=tfe.acme.internal
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 2188 bytes and written 293 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 1203266610401BE2461809F0191DB4C179AD22622C79AE86571F81A1739DF7E5
    Session-ID-ctx:
    Master-Key: FC72C066EDF1558FE7A26C2C2EF6AE6E1B25F16E7902EA447620B86FD27CCF13505E474ED1CCE8CAF78DCC938A3E80D9
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - fc 94 dd 6c d1 60 74 ac-aa 35 ce 57 29 68 23 8d   ...l.`t..5.W)h#.
    0010 - 12 0c 9e 16 09 25 23 c9-3d b3 59 ba 6f a5 d9 67   .....%#.=.Y.o..g
    0020 - a8 83 96 ce 73 9c 8b a6-3a c0 1c a5 0a 13 54 39   ....s...:.....T9
    0030 - 99 77 85 5e ee c7 c5 27-0a 64 e8 78 91 0c 48 f8   .w.^...'.d.x..H.
    0040 - cf 67 4e d7 9e a4 07 bc-ff e0 ac 07 24 aa 9e fd   .gN.........$...
    0050 - 59 b8 0e 8c cf 3a 83 6e-4e e0 ec d1 94 d1 1e 8b   Y....:.nN.......
    0060 - 88 d1 8e fb b0 76 d2 91-ad 8a 28 e5 fb 9e 77 92   .....v....(...w.
    0070 - 78 8c d0 b0 1a d2 1b 3d-d3 50 68 57 c4 fb 5b f5   x......=.PhW..[.
    0080 - c3 02 eb 65 dd 04 da 33-32 03 a8 82 5c 96 0b e1   ...e...32...\...
    0090 - 88 97 02 b9 73 33 bf 32-ba 93 f7 f5 bb 1d e7 be   ....s3.2........
    00a0 - 36 7f df ad d7 d4 89 f8-4d 7a ef 36 e2 44 2d 8c   6.......Mz.6.D-.

    Start Time: 1541044386
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
closed

main.go

package main

import (
	"io"
	"net/http"
	"os"
)

func main() {
	resp, err := http.Get("https://tfe.acme.internal/.well-known/terraform.json")
	if err != nil {
		panic(err)
	}

	io.Copy(os.Stdout, resp.Body)
}

go run main.go

panic: Get https://tfe.acme.internal/.well-known/terraform.json: x509: certificate signed by unknown authority

goroutine 1 [running]:
main.main()
        /go/main.go:12 +0xc1
exit status 2

Build provider from source and plan

bash-4.4# go version
go version go1.10.3 linux/amd64
bash-4.4# go build
bash-4.4# copy ./terraform-provider-tfe /go/bin/
bash-4.4# bash-4.4# terraform init
Initializing provider plugins...
Terraform has been successfully initialized!
.......
bash-4.4# terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
------------------------------------------------------------------------
Error: Error running plan: 1 error(s) occurred:
* provider.tfe: host tfe.acme.internal does not provide a Terraform Enterprise API

It would be good to include an environment variable for the TFE provider so that it is consistent with all of the other providers that are currently available. Something like TFE_HOSTNAME and TFE_TOKEN would suffice.

The Problem

Azure Devops has the concept of linking variables from a variable group. Additionally, it can be a secure file. Both of these can be linked to jobs, and this results in the credentials for all being able to be changed by updating the library credential, instead of having to put environment variables in every single job.

Right now, managing many workspaces requires a lot of effort with the provider as the credentials have to be embedded. This results in more change and risk in breaking things when you have many jobs requiring credential rotation

Possible Suggestions

Consider shared variables that can be linked, and then automatically available in child tasks, or some type of service connections that be leveraged.

Hey

After upgrading to use v0.10.1, we still see these always re-planned and not been set:

      file_triggers_enabled: "false" => "true"
      trigger_prefixes.#:    "0" => "1"
      trigger_prefixes.0:    "" => "tf"

#81

When I run a plan after 0.12 it appears to not be able to detect the existence/state of the tfe_variables that I have defined.

Having the ability to set Execution Modes (Remote / Local) upon workspace creation would be useful.

Per the tfe_organization_token documentation, the resource should maintain a token attribute refernce. Given the following configuration, the following error is received:

resource "tfe_organization" "my_org" {
  name                    = "My-Org"
  email                   = "${var.tfe_admin_email}"
  session_timeout_minutes = "30"
}

resource "tfe_organization_token" "my_org_token" {
  organization = "${tfe_organization.my_org.name}"
}

output "my_org_token" {
  value       = "${tfe_organization_token.my_org_token.token}"
}

Error: Error running plan: 1 error occurred:
	* output.my_org_token: Resource 'tfe_organization_token.my_org_token' does not have attribute 'token' for variable 'tfe_organization_token.my_org_token.token'

Note: organization & organization token were imported in this context. State for the org token still shows no token attribute:

"tfe_organization_token.my_org_token": {
    "type": "tfe_organization_token",
    "depends_on": [],
    "primary": {
    "id": "My-Org",
    "attributes": {
        "id": "My-Org",
        "organization": "My-Org"
    },
    "meta": {},
    "tainted": false
    },
    "deposed": [],
    "provider": "provider.tfe"
},

Terraform throws the following error when creating a variable using the tfe_resource resource with an empty value attribute.

Error: Error applying plan:

1 error(s) occurred:

* tfe_variable.use: 1 error(s) occurred:

* tfe_variable.use: Error creating env variable test_var: value is required

This error is thrown whether the category attribute is set to env or terraform. The Terraform Enterprise web interface does allow the creation of empty value variables.

The code I used to reproduce this is below.

provider "tfe" {
  token = "${var.tfe_token}"
}

variable "tfe_token" {
  type = "string"
}

variable "tfe_organization" {
  type    = "string"
  default = "example-org"
}

variable "tfe_workspace" {
  type    = "string"
  default = "example-workspace"
}

resource "tfe_workspace" "example" {
  name         = "${var.tfe_workspace}"
  organization = "${var.tfe_organization}"
}

resource "tfe_variable" "example" {
  key          = "test_var"
  value        = ""
  category     = "env"
  workspace_id = "${tfe_workspace.example.id}"
}

Maybe the value attribute in the tfe_variable resource should be marked optional.

• https://github.com/terraform-providers/terraform-provider-tfe/blob/master/tfe/resource_tfe_variable.go#L31

If so then the go-tfe might need to stop checking for a valid value.

• https://github.com/hashicorp/go-tfe/blob/master/variable.go#L132-L134

Also noting that you can create a variable within an empty value via the API even though the API documentation lists the data.attributes.value attribute as required.

Would it be possible to expose TFC IP ranges, something very similar to github_ip_ranges, aws_ip_ranges?

The use case is, if you want to use Terraform Cloud to provision configuration to ISVs, it is a security risk to open up the management public IP to the whole internet (especially if are configuring a firewall via TFC). It would be really nice if we can retrieve the IP addresses/ranges used by TFC, so the ISV management interface can be locked down to only allow requests from TFC.

Would be great to be able to read variables from a data source to pass throughout TF.

Looking for a resource to add new Terraform Versions as they become available.

Something like the following:

resource "tfe_terraform_version" "12-20" {
  enabled  = true  #Make the Terraform version available to all users.
  beta     = false #Beta Terraform versions are only available to organizations that have been granted beta access.
  url      = "https://releases.hashicorp.com/terraform/0.12.0/terraform_0.12.0_linux_amd64.zip"
  checksum = "42ffd2db97853d5249621d071f4babeed8f5fdba40e3685e6c1013b9b7b25830" #The SHA256 checksum of the downloaded Terraform version will be verified. The checksum can be found on the download page.
}

Ideally this would act as an upsert when dealing with an existing Terraform Version.
TFE currently ships with over 100 Terraform Versions.

Current Problem Of Existing Variables

If I want to update all my workspaces with tfe_variable, I find that it errors instead of replacing if the variable already exists.

I know this matters for typically terraform server behavior. However, having an option to overwrite if exists would be great, as then existing workspaces can be easily managed by updating the variables and ensuring terraform starts managing. Right now, I have to go into the workspace in Terraform Cloud, and manually delete each variable, and then then rerun the plan to reapply all the missing variables.

This results in a very brittle process if someone adds a variable manually due to time constraints, as the variable creation will then fail.

Possible Solution

Add parameter for allow_overwrite or force that would ensure if the variable already exists it would be deleted and then the apply of the variable would be allowed to proceed without error.

Hi,

I'm using tfe provider to create workspaces on Terraform Cloud. The Terrafrom version I'm using is 0.12.13. The TFE version is v0.11.1.

I created a CLI configuration file (.terraformrc) wihch contains my user token (I am owner on the organization).

I'm using a remote backend which points to "bootstrap workspace" from within I run plans and applies:

terraform {
  backend "remote" {
    organization = "my-org"
    workspaces {
      name = "bootstrap"
    }
  }
}

The main.tf looks like this

provider "tfe" {
}

resource "tfe_workspace" "my-new-workspace" {
  name         = "my-new-workspace"
  organization = my-org
}

When I run terraform initthen terraform plan it works perfectly (for example the bootstrap workspace is created automatically when it does not exist, which mean that the authentication is done correctly).

The problem is when running terraform plan, I get the following error :

Error: Error creating workspace my-new-workspace for organization my-org: resource not found

  on main.tf line 4, in resource "tfe_workspace" "my-new-workspace":
   4: resource "tfe_workspace" "my-new-workspace" {

Which made me think of an authentication problem.

After multiple tests, I ended by hardcoding the same token from .terraformrc into the provider definition.

provider "tfe" {
  token = ${var.token}
}

I also tested the TFE_TOKE environment variable (as documented here), it didn't work neither.

Did I missed something or is there a bug?

Other providers support this option, i.e.
https://github.com/terraform-providers/terraform-provider-triton#setup

This helps during initial automated setups of pTFE where you might not yet have a real signed cert to use.

I'm trying to remove tfe_workspace working_directory attribute and essentially point it to root directory of repository (default action). However removal of this attribute does not show any changes in plan. When I set working_directory = "" , that is also not showing any changes. The only way to work around this is to put space as value for working_directory.

BEFORE:

resource "tfe_workspace" "test_workspace" {
  name = "test"
  organization = "test"
  working_directory = "some_path_in_repository"
...
}

CHANEG TAKE 1:

resource "tfe_workspace" "test_workspace" {
  name = "test"
  organization = "test"
  working_directory = ""
...
}

CHANGE TAKE 2:

resource "tfe_workspace" "test_workspace" {
  name = "test"
  organization = "test"
  // removed working_directory
...
}

Result:
Both code changes resulted in no changes to plan.

Expected result:
Terraform plan should show changes that working directory is about to be set to nothing and apply default path root of repository.

Provider version tested: v0.13.0, v0.14.0

In order to import modules into TFE Organizations, a registry module resource would be very helpful. Unfortunately, it looks like the go-tfe library doesn't yet implement any functionality for the registry-modules api endpoint. Should I open an issue on that repo as well?

Hi,
It would be great to have resources in TFE provider to manage private modules registry and VCS provider in a TFE organization using terraform configurations.