-
Notifications
You must be signed in to change notification settings - Fork 113
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
Disambiguate consul backing store names to help during migration #275
Comments
One potential fix, if this is not currently supported: Instead of the current definition block:
add/allow a new definition block that allows a
|
Hi @gc-ss, this is not currently possible at the moment and would require changes in Terraform, not just the Consul backend to be able to do this. Since this is something that could improve quality of life for all backends and not just the Consul backend, I will look into a way to add more information to this message without breaking backward compatibility. |
Remi - appreciate you looking into this.
Thank You - however, I would assume you have a lot of features that are more important than this - to me this is a (potentially) superficial fix - so could you tell me:
The current message confuses (and scares!) me everytime I read it and I am happy to hire an expert/contractor to improve my quality of life but I lack the knowledge to know what needs to change (or I would have got it fixed already) - these inputs will really help me dial things in. |
Hi @gc-ss, the different Terraform backends are all a part of Terraform core so the code is at https://github.com/hashicorp/terraform, specifically the part that handles backend migration is at https://github.com/hashicorp/terraform/blob/main/internal/command/meta_backend_migrate.go, for example the confusing message for the scenario where we migrate from a consul cluster to another consul cluster is at: https://github.com/hashicorp/terraform/blob/main/internal/command/meta_backend_migrate.go#L561-L573. When those messages were added only the I don't know this part of the Terraform code well but I think it should be relatively straightforward to update it and make the message more explicit. I already started working on a PR to improve the messages and will keep you updated. |
A user reported at hashicorp/terraform-provider-consul#275 that the message when migrating backend was not detailed enough to be sure what was the previously configured backend, and what is the new one. This can make migrating from one backend to another dangerous as there is no way to check the configuration is correct when actually migrating to a new backend. The message when using the consul backend (though the issue still stands with other backends as well) was: Do you want to migrate all workspaces to "consul"? Both the existing "consul" backend and the newly configured "consul" backend support workspaces. When migrating between backends, Terraform will copy all workspaces (with the same names). THIS WILL OVERWRITE any conflicting states in the destination. Terraform initialization doesn't currently migrate only select workspaces. If you want to migrate a select number of workspaces, you must manually pull and push those states. If you answer "yes", Terraform will migrate all states. If you answer "no", Terraform will abort. I changed the Backend interface to add a String() method that returns an HCL representation of the backend and used it to return more information when migrating. The new message is: Do you want to copy existing state to the new backend? Pre-existing state was found while migrating the previous "local" backend to the newly configured "consul" backend. No existing state was found in the newly configured "consul" backend. The configuration for the previous "local" backend was: backend "local" { path = "" workspace_dir = "" } The configuration for the new "consul" backend is: backend "consul" { access_token = "" address = "" ca_file = "" cert_file = "" datacenter = "" gzip = false http_auth = "" key_file = "" lock = true path = "full/path" scheme = "" } Do you want to copy this state to the new "consul" backend? Enter "yes" to copy and "no" to start with an empty state. For the local and remote backends the implementation is straightforward, for all the others the representation is generated from the backend's Schema and its configuration.
A user reported at hashicorp/terraform-provider-consul#275 that the message when migrating backend was not detailed enough to be sure what was the previously configured backend, and what is the new one. This can make migrating from one backend to another dangerous as there is no way to check the configuration is correct when actually migrating to a new backend. The message when using the consul backend (though the issue still stands with other backends as well) was: Do you want to migrate all workspaces to "consul"? Both the existing "consul" backend and the newly configured "consul" backend support workspaces. When migrating between backends, Terraform will copy all workspaces (with the same names). THIS WILL OVERWRITE any conflicting states in the destination. Terraform initialization doesn't currently migrate only select workspaces. If you want to migrate a select number of workspaces, you must manually pull and push those states. If you answer "yes", Terraform will migrate all states. If you answer "no", Terraform will abort. I changed the Backend interface to add a String() method that returns an HCL representation of the backend and used it to return more information when migrating. The new message is: Do you want to copy existing state to the new backend? Pre-existing state was found while migrating the previous "local" backend to the newly configured "consul" backend. No existing state was found in the newly configured "consul" backend. The configuration for the previous "local" backend was: backend "local" { path = "" workspace_dir = "" } The configuration for the new "consul" backend is: backend "consul" { access_token = "" address = "" ca_file = "" cert_file = "" datacenter = "" gzip = false http_auth = "" key_file = "" lock = true path = "full/path" scheme = "" } Do you want to copy this state to the new "consul" backend? Enter "yes" to copy and "no" to start with an empty state. For the local and remote backends the implementation is straightforward, for all the others the representation is generated from the backend's Schema and its configuration.
Feature Description
I currently have a consul cluster per environment and I use consul as the backing store for Terraform.
Often, after certain internal milestones/checkpoints, I change the consul cluster that Terraform is configured to use.
When this happens, the migration message output from Terraform confuses me.
For example, assume:
consul_cluster_a
andconsul_cluster_b
.consul_cluster_a
as the backing storeconsul_cluster_a
toconsul_cluster_b
This is very confusing, to me, as I have no idea which
consul_cluster_a
orconsul_cluster_b
is being mentioned when it says"consul"
in:I would have preferred to see, something more explicit like:
My current definition block looks like this:
Please use the reaction feature (https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to add upvotes to pre-existing requests.
The text was updated successfully, but these errors were encountered: