terraform-provider-consul
terraform-provider-consul copied to clipboard
Disambiguate consul backing store names to help during migration
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:
- I have
consul_cluster_a
andconsul_cluster_b
. - the current OSS Terraform workspace uses
consul_cluster_a
as the backing store - after a while, I have to change the backing store from
consul_cluster_a
toconsul_cluster_b
- Then I see the following migration message:
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.
This is very confusing, to me, as I have no idea which consul_cluster_a
or consul_cluster_b
is being mentioned when it says "consul"
in:
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
I would have preferred to see, something more explicit like:
Do you want to migrate all workspaces to "consul_cluster_b"?
Both the existing "consul_cluster_a" backend and the newly configured "consul_cluster_b" backend
support workspaces. When migrating between backends, Terraform will copy
My current definition block looks like this:
backend "consul" {
…
}
- Is there something I can modify to get the behavior I want?
- Is this possible at all?
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.
One potential fix, if this is not currently supported:
Instead of the current definition block:
backend "consul" {
…
}
add/allow a new definition block that allows a "name tag"
:
backend "consul" "<name tag>" {
…
}
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.
I will look into a way to add more information to this message without breaking backward compatibility
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:
- Where exactly in the code changes could need to be made
- If multiple repos are involved, links could help
- How many hours you could estimate per repo?
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 local
and remote
backends existed so there was less risk of confusion.
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.