Mysterious change in additional_components_command path about terraform-google-gcloud HOT 4 CLOSED

To confirm, have you always had it hardcoded to v2.0.0? Is there any chance you updated the Terraform version?

FWIW, it should be safe to apply that command. All the script does is install additional components (gcloud alpha in this case) so applying it again is fine.

@bharathkkb Any ideas?

from terraform-google-gcloud.

@morgante yes i have had some other folks reach out to me via email regarding this. This seemed to be due to an upstream change in the Terraform registry/core. For example from our CI logs:

Aug 13, 2020:

Already have image (with digest): gcr.io/cloud-foundation-cicd/cft/developer-tools:0.12.0
Proceeding using application default credentials
Initializing modules...
Downloading terraform-google-modules/project-factory/google 8.1.0 for gke-project-1...
+ - gke-project-1 in .terraform/modules/gke-project-1/terraform-google-project-factory-8.1.0
Downloading terraform-google-modules/gcloud/google 1.4.1 for example.asm.asm_install...
+ - example.asm.asm_install in .terraform/modules/example.asm.asm_install/terraform-google-gcloud-1.4.1/modules/kubectl-wrapper

Aug 30, 2020

Already have image (with digest): gcr.io/cloud-foundation-cicd/cft/developer-tools:0.12.0
Proceeding using application default credentials
Initializing modules...
Downloading terraform-google-modules/project-factory/google 8.1.0 for gke-project-1...
+ - gke-project-1 in .terraform/modules/gke-project-1
Downloading terraform-google-modules/gcloud/google 1.4.1 for example.asm.asm_install...
+ - example.asm.asm_install in .terraform/modules/example.asm.asm_install/modules/kubectl-wrapper

This in turn triggered #75 so if you try to apply the change that is planned above, that will also fail due to path change.
The workaround suggested in #75 seemed to work for the other folks.

from terraform-google-gcloud.

Hi. Thanks for response.

@morgante I've always had my module version set as 2.0.0. The only place where I use ~> operator is:

terraform {
  required_version = "~> 0.12"

  required_providers {
    google      = "~> 3.31"
    google-beta = "~> 3.31"
    null        = "~> 2.1"
    random      = "~> 2.2"
  }
}

After this incident I set all versions explicitly to the following:

Terraform v0.12.29
+ provider.external v1.2.0
+ provider.google v3.31.0
+ provider.google-beta v3.31.0
+ provider.null v2.1.2
+ provider.random v2.3.0
+ provider.template v2.1.2

Seems like none of them has changed recently though.

@bharathkkb Thanks. I've already seen issue #75 but it seemed to me like the other problem caused by storing module version in a filesystem path. By the way, is it necessary to store full path in module's state? This causes issues when running Terraform from different machines, e.g. Github actions vs local (I know, it's an antipattern, but still):

 ~ "gcloud_bin_abs_path"    
= 
"/home/runner/work/myproject/.terraform/modules/backend.firestore_native_mode/terraform-google-gcloud-2.0.0/cache/694c9ae1/google-cloud-sdk/bin" 
-> 
"/Users/mateuszgrzechocinski/myproject/.terraform/modules/backend.firestore_native_mode/terraform-google-gcloud-2.0.0/cache/694c9ae1/google-cloud-sdk/bin"

This seemed to be due to an upstream change in the Terraform registry/core

What do you mean by this? I've been running Terraform on Github Actions using the following image, where TF version is set explicitly, so I have no idea what could have changed?

      - uses: hashicorp/setup-terraform@v1
        with:
          terraform_version: 0.12.29

I see two solutions to fix it:

1. (as you advise) Try to taint all the resources
2. Fix all wrong paths in my remote state so that plan would not try to change them

Either way, I'm disappointed I don't know why this happened and how to avoid it in the future.

from terraform-google-gcloud.

After spending some additional time for investigation I came to the following conclusions:

1. For unknown reason, around second half of Aug 2020, Terraform changed the way terraform init works
2. Due to this change, modules used by Terraform files are stored in different location.
   Before:

.terraform/modules/firestore_native_mode
└── terraform-google-gcloud-1.4.0
    ├── build
    ├── cache
    ├── examples
    ├── modules
    ├── scripts
    └── test

After:

.terraform/modules/firestore_native_mode
├── build
├── cache
├── examples
├── modules
├── scripts
└── test

3. There are modules which stores either relative or full path to itself in the Terraform state file. terraform-google-gcloud does so. In my case, state contains 34 occurrences of terraform-google-gcloud-2.0.0. One of them is:

 "resources": [
    {
      "module": "module.backend.module.firestore_native_mode",
      "mode": "data",
      "type": "external",
      "name": "env_override",
      "provider": "provider.external",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "-",
            "program": [
              ".terraform/modules/backend.firestore_native_mode/terraform-google-gcloud-2.0.0/scripts/check_env.sh"
            ],
            "query": null,
            "result": {
              "download": ""
            },
            "working_dir": null
          }
        }
      ]
    },

All of those resources plan wants to change due to no. 1
4. The easiest solution to fix this was to make a little hack on state file:

# Pull remote state to local `broken.tfstate` file
$ terraform state pull > broken.tfstate

# Make a replacement
$ sed -e "s/\/terraform-google-gcloud-2.0.0//g" broken.tfstate > fixed.tfstate

# Increase serial so that Terraform will allow to use it as a new state
$ cat fixed.tfstate | grep "serial"
  "serial": 12, <--- increment and save file

# Push fixed state 
$ terraform state push fixed.tfstate

5. After that, terraform plan no longer wants to change anything and generally behaves like expected.

I will keep this issue open for a couple of days so that maybe someone would explain no. 1. (unknown reason).

from terraform-google-gcloud.