The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created.

[sheeeng]

module "wireguard" {
  source = "[email protected]:jmhale/terraform-wireguard.git?ref=v1.0.0"
}

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

module.wireguard.data.template_file.wg_client_data_json[2]: Refreshing state...
module.wireguard.data.template_file.wg_client_data_json[0]: Refreshing state...
module.wireguard.data.template_file.wg_client_data_json[1]: Refreshing state...
module.wireguard.data.aws_ssm_parameter.wg_server_private_key: Refreshing state...
module.wireguard.data.aws_iam_policy_document.wireguard_policy_doc: Refreshing state...
module.wireguard.data.aws_iam_policy_document.ec2_assume_role: Refreshing state...
module.wireguard.data.aws_ami.ubuntu: Refreshing state...

------------------------------------------------------------------------

Warning: Interpolation-only expressions are deprecated

  on .terraform/modules/wireguard/main.tf line 64, in resource "aws_autoscaling_group" "wireguard_asg":
  64:   name                 = "${aws_launch_configuration.wireguard_launch_config.name}"

Terraform 0.11 and earlier required all non-constant expressions to be
provided via interpolation syntax, but this pattern is now deprecated. To
silence this warning, remove the "${ sequence from the start and the }"
sequence from the end of this expression, leaving just the inner expression.

Template interpolation syntax is still used to construct strings from
expressions when the template includes multiple interpolation sequences or a
mixture of literal strings and interpolations. This deprecation applies only
to templates that consist entirely of a single interpolation sequence.


Error: Invalid count argument

  on .terraform/modules/wireguard/wireguard-iam.tf line 28, in resource "aws_iam_policy" "wireguard_policy":
  28:   count              = (var.eip_id != "disabled" ? 1 : 0) # only used for EIP mode

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.


Error: Invalid count argument

  on .terraform/modules/wireguard/wireguard-iam.tf line 36, in resource "aws_iam_role" "wireguard_role":
  36:   count              = (var.eip_id != "disabled" ? 1 : 0) # only used for EIP mode

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.

[sheeeng]

@jmhale, thanks for the review on the previous pull requests.

Could you share any initial pointers to get me started on how we can fix this issue?

[jmhale]

@sheeeng This is a strange one. I'm not quite sure what's going on yet. Are you only seeing this in ALB mode, and not when using a EIP?

I'm using EIP for day-to-day stuff, and I'm not seeing this error. I'm going to switch it to using a ALB and see if I can reproduce.

[sheeeng]

Hmm. I am using the provided basic EIP example.

[jmhale]

Yeah, I think something weird is going on then. Do you have remote state? Are you able to blow away your local copy and pull from remote (rm -rf .terraform)?

I tried to switch to the ALB config, but I hit a strange cycle error when trying to destroy the existing stack, and I haven't had enough caffeine yet to try and diagnose that one.

[sheeeng]

Yes, I purged all untracked files in the cloned repository. I did not change anything inside the main.tf in the example.

➜  simple_eip git:(master) $ terraform init
Initializing modules...
Downloading [email protected]:jmhale/terraform-wireguard.git for wireguard...
- wireguard in .terraform/modules/wireguard

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "aws" (hashicorp/aws) 2.50.0...
- Downloading plugin for provider "template" (hashicorp/template) 2.1.2...

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.
➜  simple_eip git:(master) $ terraform version
Terraform v0.12.21
+ provider.aws v2.50.0
+ provider.template v2.1.2
➜  simple_eip git:(master) $ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

module.wireguard.data.template_file.wg_client_data_json[1]: Refreshing state...
module.wireguard.data.template_file.wg_client_data_json[2]: Refreshing state...
module.wireguard.data.template_file.wg_client_data_json[0]: Refreshing state...
module.wireguard.data.aws_ssm_parameter.wg_server_private_key: Refreshing state...
module.wireguard.data.aws_iam_policy_document.ec2_assume_role: Refreshing state...
module.wireguard.data.aws_ami.ubuntu: Refreshing state...
module.wireguard.data.aws_iam_policy_document.wireguard_policy_doc: Refreshing state...

------------------------------------------------------------------------

Error: Invalid count argument

  on .terraform/modules/wireguard/wireguard-iam.tf line 28, in resource "aws_iam_policy" "wireguard_policy":
  28:   count       = (var.eip_id != "disabled" ? 1 : 0) # only used for EIP mode

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.


Error: Invalid count argument

  on .terraform/modules/wireguard/wireguard-iam.tf line 36, in resource "aws_iam_role" "wireguard_role":
  36:   count              = (var.eip_id != "disabled" ? 1 : 0) # only used for EIP mode

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.

➜  simple_eip git:(master) $

I will look further into this issue in my free time. Thanks for the initial pointers!

[sheeeng]

@jmhale, what is the output of your terraform version?

[jmhale]

@sheeeng I'm using 0.12.20

Not sure of the various provider versions off the top of my head. I can grab the full output when I'm back home.

[vtknightmare]

hey @jmhale and @sheeeng I'm also having the exact same issue... any update?

[sheeeng]

@vtknightmare, sorry that I manage to further debug the issue.

[zmingxie]

The error message here suggested a workaround:

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.

Just break down terraform apply into 2 steps:

1. Provision the EIP first: terraform apply --target=aws_eip.wireguard
2. Create the rest of the stack: terraform apply

[sgarner]

The problem here is that when you pass in an Elastic IP ID as a reference to a resource attribute (i.e. when you're creating the EIP in the same plan), Terraform doesn't know the value of eip_id during plan phase. It's not allowed to use such a value in a count attribute because then Terraform doesn't know how many of the resource will be created.

Here is a proposed solution that splits out the configuration of whether to use an EIP and the EIP ID itself into separate variables (use_eip, eip_id) to avoid this issue: #26

[vainkop]

I see the same & the fix is pretty easy, so why not add to master?