-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
${terraform.workspace} value is default and not actual workspace name (when using the terraform cloud remote backend) #22802
Comments
Thanks for the bug report, @tomerliberman. I've reproduced this issue on Terraform Cloud. Edit: This is not a bug, but expecting a different value for |
we had to manually change all the terraform.workspace to var.workspace . we just started to have 1 more engineer working on terraform code and we want remote execution to prevent security risk with applying locally. but this bug really a show stopper for us for using terraform cloud. |
I am having the same issue and can't figure out why this is occuring. @kmoe Do you have an update as to when this will be corrected? |
We're seeing the same behavior with Timeline for a fix would be greatly appreciated. |
terraform v0.12.9 - same behavior. |
One weird thing is when debugging with `
` |
Same issue here. I must to add static value for data "terraform_remote_state" "tfcloud" {
backend = "remote"
config = {
organization = "org"
#static will work, but can't use for another workspace
#workspaces = {
# name = "mywrk-prd"
#}
# I want to set like this but doesn't work
workspaces = {
prefix = "mywrk-"
}
}
}
terraform {
backend "remote" {
hostname = "app.terraform.io"
organization = "org"
workspaces = {
prefix = "mywrk-"
}
}
} $ terraform --version
Terraform v0.11.13
+ provider.archive v1.3.0
+ provider.aws v2.30.0
+ provider.template v2.1.2
$ terraform workspace list
* prd
$ terraform plan
...
To view this run in a browser, visit:
https://app.terraform.io/app/mycorp/mywrk/runs/run-xxx
Waiting for the plan to start...
Terraform v0.11.13
Configuring remote state backend...
...
Error: Error refreshing state: 1 error(s) occurred:
* data.terraform_remote_state.tfcloud: 1 error(s) occurred:
* data.terraform_remote_state.tfcloud: data.terraform_remote_state.tfcloud: error loading the remote state: default state not supported
You can create a new workspace with the "workspace new" command. |
This is not actually a bug. It is important to understand that the concept of "workspace" in TFC is different from the one in open source Terraform. In the latter (sometimes called a "local workspace"), the This does mean that Terraform configurations that use that interpolation must be modified to not use it for TFC if doing remote runs on TFC or TFE. Please see https://www.terraform.io/docs/cloud/migrate/workspaces.html for instructions on migrating multiple local workspaces to TFC. |
Thank you for your comment reberlind. I've read the guide that you shared, it is still not intuitive. Anyways - I simply recommend people to tick the "run locally" and then everything works as expected. |
Forgive me @rberlind, but I'm having trouble resolving how this with how To provide examples, iven a main backend of:
And a set of workspaces such as:
|
Thanks for your feedback, @dekimsey. When I described the differences between the "workspace" concepts in Terraform OSS and Terraform Cloud (and Terraform Enterprise), I neglected to mention how the remote backend can help customers map between them. Your comment referring to the Specifically, if you have a Terraform OSS configuration in a directory with multiple workspaces such as "dev", "qa", and "prod", you can set up the remote backend with the Note that the The bottom line with regard to the Note that the TFC/TFE workspaces will be created for you if they do not already exist and will use the most recent version of Terraform OSS. However, if your workspace needs variables set, especially environment variables such as cloud credentials, you should manually create the workspaces and set any needed variables. If you want to use a version of Terraform OSS for the runs done on the TFC/TFE server in those workspaces, then you should also set the version before your first plan or apply. Regarding use of remote backend with the Hopefully, that clarifies how Terraform OSS workspaces can be mapped to TFC/TFE workspaces with the remote backend configuration as well as why the |
This PR seeks to clarify distinctions between the TF OSS and Terraform Cloud workspace concepts in order to avoid confusion such as that shown in #22802 and #21507. It also clarfies that the `prefix` key cannot be used when configuring the terraform-remote_state data source. It also points out that the `${terraform.workspace}` interpolation should not be used in Terraform code used in remote runs on TFC workspaces.
I was also surprised by this when transitioning from local runs to remote runs and saw that my resources (that was tagged with the Would love to keep using the |
This is rather confusing, but I think the major issue is simply:
And since the remote execution mode has a different behavior with regards to the local when it comes to workspaces -- specifically In the Web GUI, go to the workspace in question, select |
Thanks for sharing your thoughts on this, @keithrozario. It is true that workspace execution mode does default to remote. That is probably because remote execution used to be the only option before the introduction of "Terraform Cloud" which was a new product that essentially replaced the HashiCorp-hosted implementation of "Terraform Enterprise". I will file an internal ticket asking whether the Terraform Cloud team thinks that defaulting to local execution mode would be better, at least for customers using the free tier of Terraform Cloud who are most likely to want that. I'm also adding a ticket asking that execution mode be documented under https://www.terraform.io/docs/cloud/workspaces/settings.html#general |
For anyone needing a quick workaround, variable "ATLAS_WORKSPACE_NAME" {
type = string
} |
This comment has been minimized.
This comment has been minimized.
thanks @rberlind , yea, as a free-tier user I struggled to understand why my new workspaces were not deploying. Also, it warned me about a state file as I deployed :( Would have been helpful if the error message prompted something. |
I've just read through all the replies and .. TL;DR- I recommend to anyone who's using Terraform to use "run locally" and make sure all the architects have the same version of Terraform, and relevant provider(s) extra software installed. Since this "run remotely" is not acting as expected by the common user (or to anyone with common sense) it's "simpler" to design a solution that runs locally. |
@unfor19 : I would note that there are some advantages of doing remote runs with Terraform Cloud including having the runs history for each workspace along with the plan and apply logs and Sentinel policy check logs if Sentinel is used. With local runs, you are only using Terraform Cloud for storing state and cannot use Sentinel policies to restrict the resources being provisioned. |
Also worth mentioning VCS integration which is the reason I transitioned from local to remote runs. It has worked really well (great work!), so no reason to complain other than this small nit. |
agreed |
@rberlind Thank you for your explanations. What's the suggested future-proof way of retrieving the name of the current TFC workspace? While the approach with the environment variable might work right now, you mentioned that this is an internal implementation detail, which might change, so I wonder if there is a better way to get the TFC workspace name. |
I cannot share that with you yet, @Dunedan, since the product management and engineering teams are working on improving the use of Terraform OSS workspace names in Terraform Cloud and Terraform Enterprise. At this time, every TFC/TFE workspace will only have the "default" Terraform OSS workspace under the covers. However, I also want to point out that I misinterpreted what @SeanHood has written in his comment suggesting using the TF_VAR_ATLAS_WORKSPACE_NAME environment variable and the ATLAS_WORKSPACE_NAME Terraform variable. That is something that can always be done, also in the future. I had mistakenly thought he was referring to a pre-defined environment variable that might have existed at some point in the past and might still exist even though I could find no reference to it. (I had neglected to note that it started with "TF_VAR_".) I'm going to delete that confusing comment. The one suggestion I would make is that you use a different name such as tfc_workspace_name for the Terraform variable and TF_VAR_tfc_workspace_name for the environment variable. "Atlas" refers to a very old version of Terraform Cloud (and Terraform Enterprise) and should really not be used. In fact, it was the use of "ATLAS" that made me thing @SeanHood was referring to some predefined environment variable. I still should have noticed the TF_VAR_ prefix though. |
Now I'm more confused than before, because |
Apologies @Dunedan and other readers. I'm obviously also confused. I'm reshowing my original comment (which I had hidden, not deleted). I'll ask the Terraform engineering team about this. If you are correct that "TF_VAR_ATLAS_WORKSPACE_NAME is a pre-defined environment variable in Terraform Cloud", I do not believe that fact is documented. Given the use of "ATLAS" in the name, I wonder if this is from the legacy version of Terraform Enterpise. I searched old versions of the docs in GitHub, but did not find it in https://github.com/hashicorp/terraform-website/blob/32b778a42ad3c49498af5ce8a9273ca0d7537bb3/content/source/docs/enterprise/runs/variables-and-configuration.html.md which mentioned various other ATLAS_ env vars. |
@Dunedan: I would note that the use of |
Hi all, TF Support Engineer here. I have assisted with numerous instances of this confusion, so please allow me to chime in. The OSS engineering team is primarily concerned with the CLI I'll be happy to address any additional questions you may have. The When the When the In TFE, the backend configuration is always overridden. This ensures that the TFE remote state storage backend for that workspace is always used regardless as to any other backend present in the configuration. The backend override is the remote backend with the It's unfortunately possible to have a configuration locally with a workspace There are some alternative approaches to keying off of the workspace name. For one, you could create a variable named There is a variable that should be available in TFE that will work for this purpose. At times it is informative to poke at the container used in TFE to see what is set and what the container layout is like. Here is the output of
In particular there is an environment variable called https://www.terraform.io/docs/configuration/environment-variables.html#tf_var_name Therefore, to make this variable available in your Terraform configuration, declare it as:
And then it should be possible to use it in the configuration:
Please note that this is an implementation detail of TFE and is likely to change, if for no other reason, due to the use of the term |
Thanks @fprimex ! |
I see new TFC_WORKSPACE_NAME can be used in tfc remote runs :-) |
@valery-zhurbenko : Unfortunately, that is the TFC-level workspace name, not the TF OSS workspace name. It is still the case that the only TF OSS workspace name associated with a TFC/TFE workspace is the "default" OSS workspace. |
I'm using the prefix and all the environment variables include the prefix. There doesn't seem to be a way to just get the workspace name as set by All of these include the prefix:
|
Hi, Here's what I've set up to retrieve the correct name for the workspace terraform {
backend "remote" {
hostname = "app.terraform.io"
organization = "my-organization"
workspaces {
prefix = "my-workspace-" # copy your workspace prefix on trimprefix("${var.TFC_WORKSPACE_NAME}", "my-workspace-") function
}
}
}
variable "TFC_WORKSPACE_NAME" {
type = string
default = "" # An error occurs when you are running TF backend other than Terraform Cloud
}
locals {
# If your backend is not Terraform Cloud, the value is ${terraform.workspace}
# otherwise the value retrieved is that of the TFC_WORKSPACE_NAME with trimprefix
my_workspace_env = var.TFC_WORKSPACE_NAME != "" ? trimprefix("${var.TFC_WORKSPACE_NAME}", "my-workspace-") : "${terraform.workspace}"
}
output "workspace" {
value = local.my_workspace_env
} If you have a better temporary solution... |
An alternative below. This allows you to set a workspace name in your remote execution environment via locals {
# if the workspace name is "default" (such as any run in Terraform Cloud), see
# if var.indicated_workspace is different from the active workspace
workspace_name = terraform.workspace == "default" ? var.indicated_workspace : terraform.workspace
}
variable "indicated_workspace" {
default = "default"
description = <<EOF
This is the workspace indicated via the environment or some other mechanism. This is useful in
an remote execution environment where the workspace name will not necessary be the same as the active
workspace of your local environment, such as when using remote execution in Terraform Cloud.
EOF
} So If I am in my workspace The nice thing here is that I do not need to specify |
Hi all! Reviewing the discussion here, it seems like this issue was representing a question, and that question has now been answered so I'm going to close the issue. We typically don't use GitHub issues for questions but I understand that at first this seemed like a bug report and only in subsequent discussion did we switch to talking about the details of the current behavior. If you have any further questions related to this, I'd suggest starting a topic in the community forum. The Terraform Core and Terraform Cloud teams are continuing to discuss the future of workspaces in Terraform CLI and so the details discussed here might change slightly in future releases, but after reading through the discussion it seems to be correct and current at the time I'm writing this. If you have bug reports or feedback about Terraform Cloud in particular, you can also contact the Terraform Cloud support team at tf-cloud-support@hashicorp.com. If you contact the support team, be sure to include your Terraform Cloud username and organization name in your request. |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Terraform Version
Terraform Configuration Files
Debug Output
Crash Output
Expected Behavior
Would use actual Cloud Workspace to make the decision
Actual Behavior
terraform.workspace value was "default" and resulted in wrong configuration
Steps to Reproduce
follow this example and use within the cloud offering with a workspace named anything other than default
(https://www.terraform.io/docs/state/workspaces.html#current-workspace-interpolation)
Additional Context
References
The text was updated successfully, but these errors were encountered: