hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
https://www.terraform.io/
Other
42.48k stars 9.51k forks source link

init: Show Terraform Enterprise hostname when proposing to migrate to the Cloud integration #32132

Open jaredbrogan opened 1 year ago

jaredbrogan commented 1 year ago

Terraform Version

v1.2.8

Terraform Configuration Files

terraform {
  required_providers {
    venafi = {
      source  = "venafi/venafi"
      version = "~> 0.10.0"
    }
    azurerm = {
      version = "~> 3.0"
    }
    random = {
      version = "~> 3.0"
    }
  }

  cloud {
    hostname     = "tfe.redacted.com"
    organization = "redacted"

    workspaces {
      name = "redacted"
    }
  }
}

Debug Output

n/a

Expected Behavior

14:02:12 $ terraform init

Initializing Terraform Enterprise...
Migrating from backend "remote" to Terraform Enterprise.

Initializing provider plugins...
- terraform.io/builtin/terraform is built in to Terraform
- Reusing previous version of venafi/venafi from the dependency lock file
- Reusing previous version of hashicorp/azurerm from the dependency lock file
- Reusing previous version of hashicorp/random from the dependency lock file
- Using previously-installed venafi/venafi v0.10.2
- Using previously-installed hashicorp/azurerm v3.29.1
- Using previously-installed hashicorp/random v3.4.3

Terraform Enterprise has been successfully initialized!

You may now begin working with Terraform Enterprise. Try running "terraform plan" to
see any changes that are required for your infrastructure.

If you ever set or change modules or Terraform Settings, run "terraform init"
again to reinitialize your working directory.

Actual Behavior

14:02:12 $ terraform init

Initializing Terraform Cloud...
Migrating from backend "remote" to Terraform Cloud.

Initializing provider plugins...
- terraform.io/builtin/terraform is built in to Terraform
- Reusing previous version of venafi/venafi from the dependency lock file
- Reusing previous version of hashicorp/azurerm from the dependency lock file
- Reusing previous version of hashicorp/random from the dependency lock file
- Using previously-installed venafi/venafi v0.10.2
- Using previously-installed hashicorp/azurerm v3.29.1
- Using previously-installed hashicorp/random v3.4.3

Terraform Cloud has been successfully initialized!

You may now begin working with Terraform Cloud. Try running "terraform plan" to
see any changes that are required for your infrastructure.

If you ever set or change modules or Terraform Settings, run "terraform init"
again to reinitialize your working directory.

Steps to Reproduce

  1. terraform init

Additional Context

n/a

References

Per this document: https://developer.hashicorp.com/terraform/cli/cloud/settings#hostname The hostname argument is solely for the purpose of using a TFE instance, so I would expect the output of commands to reflect that instead of "Cloud".

This wasn't an issue prior due to how the backend block would be generic enough in its output to not really matter. However, for those that use TFE and are transitioning from backend to cloud, this is a bit of a shock when first encountered (especially since when you have a non-empty state it prompts you to migrate).

apparentlymart commented 1 year ago

Hi @jaredbrogan!

Terraform Enterprise is the self-hosted edition of Terraform Cloud, so in this context the brand "Terraform Cloud" is referring generically to both the managed version on app.terraform.io and to the self-hosted version which you deploy at your own hostname. From the perspective of Terraform CLI, these two are indistinguishable: they both implement the same API and use the same Terraform Cloud features.

It sounds like what you found most troublesome here is that the migration prompts didn't affirm that you were using a hostname other than app.terraform.io and so you were worried that it might be about to migrate to the managed version. Is that right? If so, would it satisfy you for the initial prompt to mention the configured hostname, to confirm exactly what is the target for the migration?

14:02:12 $ terraform init

Initializing Terraform Cloud...
Migrating from backend "remote" to Terraform Cloud at tfe.redacted.com.

Initializing provider plugins...
(and everything else, unchanged)

My intent with this proposal is that terraform init would add this additional note if the hostname is anything other than the default hostname of app.terraform.io, because folks who are using the managed version don't typically specify an explicit hostname.

jaredbrogan commented 1 year ago

Hi @jaredbrogan!

Terraform Enterprise is the self-hosted edition of Terraform Cloud, so in this context the brand "Terraform Cloud" is referring generically to both the managed version on app.terraform.io and to the self-hosted version which you deploy at your own hostname. From the perspective of Terraform CLI, these two are indistinguishable: they both implement the same API and use the same Terraform Cloud features.

It sounds like what you found most troublesome here is that the migration prompts didn't affirm that you were using a hostname other than app.terraform.io and so you were worried that it might be about to migrate to the managed version. Is that right? If so, would it satisfy you for the initial prompt to mention the configured hostname, to confirm exactly what is the target for the migration?

14:02:12 $ terraform init

Initializing Terraform Cloud...
Migrating from backend "remote" to Terraform Cloud at tfe.redacted.com.

Initializing provider plugins...
(and everything else, unchanged)

My intent with this proposal is that terraform init would add this additional note if the hostname is anything other than the default hostname of app.terraform.io, because folks who are using the managed version don't typically specify an explicit hostname.

Yes, you are correct. A small change such as that should be enough in my opinion. 😃

apparentlymart commented 1 year ago

Great, thanks for confirming that!

In that case, we'll use this issue to represent enhancing the init output to be explicit about which hostname is active in the configuration whenever it isn't the default hostname.