Skip to content
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

Open
gc-ss opened this issue Jul 16, 2021 · 4 comments
Open

Disambiguate consul backing store names to help during migration #275

gc-ss opened this issue Jul 16, 2021 · 4 comments

Comments

@gc-ss
Copy link

gc-ss commented Jul 16, 2021

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 and consul_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 to consul_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" {
      …
    }
  1. Is there something I can modify to get the behavior I want?
  2. 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.

@gc-ss
Copy link
Author

gc-ss commented Jul 17, 2021

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>" {
  …
}

@remilapeyre
Copy link
Collaborator

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.

@gc-ss
Copy link
Author

gc-ss commented Aug 27, 2021

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:

  1. Where exactly in the code changes could need to be made
  2. If multiple repos are involved, links could help
  3. 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.

@remilapeyre
Copy link
Collaborator

remilapeyre commented Aug 31, 2021

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.

remilapeyre added a commit to remilapeyre/terraform that referenced this issue Sep 13, 2021
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.
remilapeyre added a commit to remilapeyre/terraform that referenced this issue Sep 13, 2021
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants