Invalid count argument error

[alvarolorentedev]

Currently getting an error when using the module: Error

Error: Invalid count argument

  on .terraform/modules/gcloud/main.tf line 57, in resource "random_id" "cache":
  57:   count = (! local.skip_download) ? 1 : 0

The "count" value depends on resource attributes that cannot be determined
until apply, so Terraform cannot predict how many instances will be created.
To work around this, use the -target argument to first apply only the
resources that the count depends on.

Module

module "gcloud" {
  source                = "terraform-google-modules/gcloud/google"
  version               = "~> 2.0"
  gcloud_sdk_version    = "304.0.0"
  platform              = "linux"
  additional_components = ["beta"]
  skip_download         = "false"
  count = 1

  create_cmd_triggers = {
    timestamp = local.timestamp
  }

  service_account_key_file = "secrets/terraform-user-credentials.json"

  create_cmd_entrypoint = "scripts/runGcloudCommands.sh"

  depends_on = [module.composer]
}

Environment

• Terraform version: 0.13.3
• hashicorp/external: version = "~> 1.2.0"
• hashicorp/google: version = "~> 3.41.0"
• hashicorp/google-beta: version = "~> 3.41.0"
• hashicorp/null: version = "~> 2.1.2"
• hashicorp/random: version = "~> 2.3.0"

[LangdalP]

I can confirm that I am experiencing the same issue. Searches on the Internet indicates that this started happening to people after upgrading to Terraform version 0.13.x.

[pinglin]

I am encountering the same issue as well. Wondering if there is a quick workaround. This has blocked all our regular plan/apply routines.

[davidmontoyago]

Experiencing the same issue while trying to provision Workload Identities with pre-existing KSAs using terraform-google-kubernetes-engine/tree/v12.0.0/modules/workload-identity.

• terraform 0.13.4
• hashicorp/google 3.47.0

[morgante]

Thanks for the reports everyone. So far I've been unable to replicate, but clearly it's an issue. @bharathkkb Have you run into this?

[bharathkkb]

@morgante yes, I was able to repro from the initial config and TF 0.13.5

module "foo" {
  source                = "terraform-google-modules/gcloud/google"
  version               = "~> 2.0"
  skip_download         = "false"
}

module "bar" {
  source                = "terraform-google-modules/gcloud/google"
  version               = "~> 2.0"
  skip_download         = "false"
  depends_on = [module.foo]
}

@kanekotic could you try using module_depends_on instead?

@davidmontoyago did annotate-sa in the workload-identity module complain? We dont use depends_on in there but if you have an example config to reproduce that would be great!

[bharathkkb]

This looks like a side effect of https://www.terraform.io/upgrade-guides/0-13.html#data-resource-reads-can-no-longer-be-disabled-by-refresh-false

In a very simplified config, problem stems from count = data.external.env_override.result.download ? 1 : 0. When I do tf refresh with a module level depends_on

module.foo.data.external.env_override[0]: Refreshing state...

vs when I do it without module level depends_on

module.foo.data.external.env_override[0]: Refreshing state... [id=-]
module.bar.data.external.env_override: Refreshing state...

[alvarolorentedev]

will give it a try and let you know first thing on monday

[davearata-snorack]

we are able to reproduce without a module level depends_on. Any other workarounds available?

[bharathkkb]

Hi @davearata-snorack Could you post a MCVE of this occurring without the depends_on? What version of Terraform?

[zxpower]

Tried today with:

• Terraform v0.14.3
• hashicorp/google v3.52.0

Issue still persists if depends_on is turned on module level. Any updates on when this will be fixed? 🤔

[MeNsaaH]

module "apply-extra-manifests" {
  source  = "terraform-google-modules/gcloud/google//modules/kubectl-wrapper"
  version = "~> 2.0.2"

  skip_download    = true
  cluster_name     = var.cluster_name
  cluster_location = var.location
  project_id       = var.project_id

  kubectl_create_command  = "kubectl apply ${local.extra_manifests}"
  kubectl_destroy_command = "kubectl delete ${local.extra_manifests}"
}

@bharathkkb this is an example of it not working without the depends_on set on module level. Terraform version 0.13.3

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

[morgante]

@bharathkkb Do you know if this is still a bug in new Terraform versions?

[bharathkkb]

@morgante this should still be an error with module depends_on as the data source eval will be pushed to apply time. I haven't encountered this with other cases but based on this comment, this is WAI.

Considering we have been steadily reducing the usage of gcloud module we could also consider dropping the env var and requiring plumbing to support this.

[morgante]

Considering we have been steadily reducing the usage of gcloud module we could also consider dropping the env var and requiring plumbing to support this.

I'd like to avoid that, as I still prefer the env variable approach to having to plumb through variables.

We should try to switch to native resources as much as possible though.

[lubouski]

Dear google team, faced the. same issue with kubectl-wrapper module terraform version: Terraform v1.0.2 on darwin_amd64

terraform init                                                                                                                 
Initializing modules...

Initializing the backend...

Initializing provider plugins...
- Reusing previous version of hashicorp/random from the dependency lock file
- Reusing previous version of hashicorp/external from the dependency lock file
- Reusing previous version of hashicorp/google-beta from the dependency lock file
- Reusing previous version of hashicorp/google from the dependency lock file
- Reusing previous version of hashicorp/null from the dependency lock file
- Using previously-installed hashicorp/random v3.1.0
- Using previously-installed hashicorp/external v2.1.0
- Using previously-installed hashicorp/google-beta v3.75.0
- Using previously-installed hashicorp/google v3.75.0
- Using previously-installed hashicorp/null v3.1.0

Terraform has been successfully initialized!

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

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

module "kubectl" {
  source = "terraform-google-modules/gcloud/google//modules/kubectl-wrapper"
  depends_on              = [google_container_cluster.primary]
  project_id              = var.service_google_project
  cluster_name            = google_container_cluster.primary.name
  cluster_location        = google_container_cluster.primary.location
  additional_components   = ["kubectl", "kpt", "beta"]
  kubectl_create_command  = "./scripts/install_asm.sh ${var.service_google_project} ${google_container_cluster.primary.name} ${google_container_cluster.primary.location} asm-downloads"
  kubectl_destroy_command = "./scripts/destroy_asm.sh"
}

Error

terraform plan                                                                                                                 
╷
│ Error: Invalid count argument
│
│   on .terraform/modules/kubectl/main.tf line 57, in resource "random_id" "cache":
│   57:   count = (! local.skip_download) ? 1 : 0
│
#resource "null_resource" "install_asm" {
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this,
│ use the -target argument to first apply only the resources that the count depends on.
╵

[morgante]

@lubouski Can you try using module_depends_on instead of depends_on as a workaround?

[gtankovics]

any update regarding this? the problem still occurs in version 1.0.5.

I've tried using as @zxpower. There's a parent module which has depends_on but this module contains only module_depends_on.

[DanielHabenicht]

@lubouski Can you try using module_depends_on instead of depends_on as a workaround?

This works! Thanks.

[fancybear-dev]

Having the same issue here; https://github.com/terraform-google-modules/terraform-google-cloud-operations

Tested with TF version v0.15.3 and v1.0.4.

[fancybear-dev]

What I did for now was just get all my relating repos offline, change the sources (so they point to the local files, and not remote github) and change the breaking line of code;

In the locals dict, change the skip_download to true, instead of the if statement. That solves it for me. Don't want to lose any more time on this as well, and is fine for now. Note that this is not future proof, as you won't have the latest repo's.

[ghost]

@lubouski Can you try using module_depends_on instead of depends_on as a workaround?

This worked for me.

[djbingham]

Considering we have been steadily reducing the usage of gcloud module we could also consider dropping the env var and requiring plumbing to support this.

I'd like to avoid that, as I still prefer the env variable approach to having to plumb through variables.

We should try to switch to native resources as much as possible though.

@morgante Could we rename the GCLOUD_TF_DOWNLOAD variable to something like TF_VAR_GCLOUD_DOWNLOAD?

According to a Terraform support article, Terraform can directly access environment variables with a TF_VAR_ prefix, so that would allow the env_override data source to be removed.

[shawlz]

I'm still getting this error on Terraform 1.2.5 and terraform module terraform-google-modules/kubernetes-engine/google v21.2.0 when using ASM

Error: Invalid count argument
on .terraform/modules/asm.cpr/main.tf line 57, in resource "random_id" "cache":
  count = (!local.skip_download) ? 1 : 0
The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.

module "asm" {
  source           = "registry.terraform.io/terraform-google-modules/kubernetes-engine/google//modules/asm"
  version          = "21.2.0"
  project_id       = local.gcp_project_id
  cluster_name     = local.gke_cluster_name
  cluster_location = module.gke.location
  enable_cni       = false

  enable_fleet_registration = true
  enable_mesh_feature       = false

  depends_on = [
    module.gke
  ]
}

Any help would be really appreciated.

[apeabody]

I'm still getting this error on Terraform 1.2.5 and terraform module terraform-google-modules/kubernetes-engine/google v21.2.0 when using ASM

Error: Invalid count argument
on .terraform/modules/asm.cpr/main.tf line 57, in resource "random_id" "cache":
  count = (!local.skip_download) ? 1 : 0
The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.

module "asm" {
  source           = "registry.terraform.io/terraform-google-modules/kubernetes-engine/google//modules/asm"
  version          = "21.2.0"
  project_id       = local.gcp_project_id
  cluster_name     = local.gke_cluster_name
  cluster_location = module.gke.location
  enable_cni       = false

  enable_fleet_registration = true
  enable_mesh_feature       = false

  depends_on = [
    module.gke
  ]
}

Any help would be really appreciated.

Hi @shawlz Could you try replacing depends_on = with module_depends_on =?

[shawlz]

@apeabody Yes, here is what I got

Error: Unsupported argument
on anthos.tf line 26, in module "asm":
  module_depends_on = [
An argument named "module_depends_on" is not expected here

[apeabody]

@shawlz Ahh, I see now you are using the asm sub-module. I've open a Feature Request to investigate https://github.com/terraform-google-modules/terraform-google-gcloud/issues/121

[shawlz]

@shawlz Ahh, I see now you are using the asm sub-module. I've open a Feature Request to investigate #121

Thanks @apeabody

[headegg]

Hi @apeabody. I've run into the same issue with the workload-identity sub-module. I see the fix that you made to asm under Feature Request #121, adding a module_depends_on var to the module and wiring it in where you use kubectl-wrapper. I tried the same thing in my local workload-identity module and it fixed the problem. Could you please look into applying this to workload-identity?

Am I going about requesting this the right way? Apologies if not. Thanks for a fantastically useful module.

[apeabody]

Hi @headegg - Thanks for reaching out! Typically I would suggest opening a fresh feature request, but not to worry as I've created the pull request for workload-identity which you can track here: https://github.com/terraform-google-modules/terraform-google-kubernetes-engine/pull/1341