aws_appstream_fleet_stack_association not working correctly

[pmcenery-bl]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform AWS Provider Version

Affected Resource(s)

• aws_appstream_fleet_stack_association

Terraform Configuration Files

The example provided here does not seem to create an aws_appstream_fleet_stack_association in the state, yet the association itself seems to be created in AWS.

resource "aws_appstream_stack" "stack" {
  count = local.appstream.create_as ? 1 : 0

  name         = "Stack"

  tags = local.tags
}

resource "aws_appstream_fleet" "fleet" {
  count = local.appstream.create_as ? 1 : 0

  name                               = "Fleet"
  image_name                         = "Firefox-Image"
  instance_type                      = "stream.standard.small"
  idle_disconnect_timeout_in_seconds = 3600
  enable_default_internet_access     = false
  fleet_type                         = "ALWAYS_ON"

  compute_capacity {
    desired_instances = 2
  }

  vpc_config {
    subnet_ids         = module.vpc.private_subnets
  }

  tags = local.tags
}

resource "aws_appstream_fleet_stack_association" "stack_fleet" {
  count = local.appstream.create_as ? 1 : 0

  fleet_name = aws_appstream_fleet.fleet.0.name
  stack_name = aws_appstream_stack.stack.0.name
}

Expected Behavior

The association should be created in the state

Actual Behavior

Terraform believes that the association was not created in a subsequent run, and then tries to create it - but finds that it already exists. You then have to import the resource manually.

If you then update or taint a stack, there appears to be a missing dependency to re-create the association.

Steps to Reproduce

1. Create the resources in the example or the above code.
2. Update the stack definition or taint it.
3. Try to apply it

Output (new resource)

Error: error reading AppStream Fleet Stack Association (Stack/Fleet): No stack "Fleet" associated with fleet "Stack"

Output (updating stack resource)

aws_appstream_stack.stack[0]: Destroying... [id=Stack]

Error: error deleting Appstream Stack (Stack): ResourceInUseException: Cannot delete stack Stack. This stack has fleets associated with it. Only stacks with no fleets associated with it can be deleted.

Looking at the creating a resource error output, it looks like "fleet_name" and "stack_name" are somehow inverted somewhere in the logic. I have double checked my references and they are correct - which leads me to believe they might be swapped in the logic of the provider somehwere...

[hblackmcn]

I am facing the exact issue! any solution to resolve this issue?

[pmcenery-bl]

I am facing the exact issue! any solution to resolve this issue?

The workaround appears to be to import the resource. It seems to create correctly, but never end up in the state. After you import it, the state seems consistent.

[tonnamb]

A temporary workaround (until this bug is fixed), that I'm testing is:

resource "null_resource" "anno_associate_fleet_stack" {
  # Requires the fleet and stack to be provisioned first. This also ensures
  # that the disassociation occurs before the fleet and stack are destroyed.
  depends_on = [aws_appstream_fleet.fleet,
                aws_appstream_stack.stack]

  triggers = {
    appstream_fleet = aws_appstream_fleet.fleet.id
    appstream_stack = aws_appstream_stack.stack.id
  }

  provisioner "local-exec" {
    command = "aws appstream associate-fleet --fleet-name Fleet --stack-name Stack"
  }

  provisioner "local-exec" {
    when = destroy
    command = "aws appstream disassociate-fleet --fleet-name Fleet --stack-name Stack"
  }
}

EDIT: from testing, this works some times, but it's still flaky with some inconsistent terraform state errors.

[zulizzi-cfg]

Moved my comment from the duplicate issue.

The bug seems to be caused by this line:

terraform-provider-aws/internal/service/appstream/fleet_stack_association.go

Line 69 in 60bd245

d.SetId(EncodeStackFleetID(d.Get("stack_name").(string), d.Get("fleet_name").(string)))

Where the arguments to EncodeStackFleetID are not in the right order.

The function for reference:

func EncodeStackFleetID(fleetName, stackName string) string {
	return fmt.Sprintf("%s/%s", fleetName, stackName)
}

[joshmears169]

Any update on this at all? Appreciate any help!

[OmkarEnjem]

facing the same error,any fix for this..

[rednevals]

I have the same issue...

When I build a fleet/stack, including the stack association resource, the apply runs and I get this error:

Error: error reading AppStream Fleet Stack Association (My-Stack/My-Fleet): No stack "My-Fleet" associated with fleet "My-Stack"

Notice the names are reversed in the error message, "No stack "My-Fleet" associated"...

When viewing from the AWS console, the stack and fleet are associated correctly. Next I tried to add a dependency in attempt to give Terraform some "guidance".

resource "aws_appstream_fleet_stack_association" "fleet_stack_association" {
  stack_name = aws_appstream_stack.my_stack.name
  fleet_name = aws_appstream_fleet.my_fleet.name

  depends_on = [aws_appstream_stack.my_stack, aws_appstream_fleet.my_fleet]
}

I still get the error. When destroying, I get these errors:

Error: error deleting Appstream Fleet (My-Fleet): ResourceInUseException: The fleet My-Fleet is associated with a stack. To delete the fleet, you must dissociate it from the stack.

Error: error deleting Appstream Stack (My-Stack): ResourceInUseException: Cannot delete stack My-Stack. This stack has fleets associated with it. Only stacks with no fleets associated with it can be deleted.

I have been using arnvid/terrafrom-provider-appstream without this issue. I was trying to convert to using hashicorp/aws but this issue is a blocker for sure.

[maati55]

I have the same issue
using: hashicorp/aws v4.6.0

resource "aws_appstream_fleet_stack_association" "example" {
   fleet_name = aws_appstream_fleet.this.name
   stack_name = aws_appstream_stack.stack.name
}

Error: error reading AppStream Fleet Stack Association (AppStreamStack/wav-dev-asf): No stack "wav-dev-asf" associated with fleet "AppStreamStack"

Any update on this, please?

[rednevals]

A temporary workaround (until this bug is fixed), that I'm testing is:

resource "null_resource" "temp_associate_fleet_stack" {
  # Requires the fleet and stack to be provisioned first. This also ensures
  # that the disassociation occurs before the fleet and stack are destroyed.
  depends_on = [aws_appstream_fleet.fleet,  aws_appstream_stack.stack]

  triggers = {
    appstream_fleet = aws_appstream_fleet.fleet.id
    appstream_stack = aws_appstream_stack.stack.id
  }

  provisioner "local-exec" {
    command = "aws appstream associate-fleet --fleet-name ${self.triggers.appstream_fleet} --stack-name ${self.triggers.appstream_stack}"
  }

  provisioner "local-exec" {
    when = destroy
    command = "aws appstream disassociate-fleet --fleet-name ${self.triggers.appstream_fleet} --stack-name ${self.triggers.appstream_stack}"
  }
}

Edits:
- From testing, this works some times, but it's still flakey with some inconsistent terraform state errors.
- Modified each provisioner to get stack/fleet names from triggers.

This worked for me... But we really need a permanent fix. It's only one line of code ;)

[hasnain-tahir]

this issue is still open @rednevals has find this quick fix which I tested and it is working

[rednevals]

FYI: I sent an email with details to one of the contributors of the commit that caused this issue. Hopefully they will respond. I will create a PR if needed...

[nieldejonghe]

Just chiming in here to say I have the same issue and would like to see this solved :)

[hasnain-tahir]

I have closed the project and just fix it via the cli

…

On Tue, May 17, 2022, 7:52 PM Niel Dejonghe ***@***.***> wrote: Just chiming in here to say I have the same issue and would like to see this solved :) — Reply to this email directly, view it on GitHub <#22625 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK44H3C5BCYHGF2NNQWBM7LVKOXEPANCNFSM5MEZISCQ> . You are receiving this because you commented.Message ID: ***@***.***>

[nieldejonghe]

@hasnain-tahir you mean you fixed it by using the workaround provided by @rednevals ?

[hasnain-tahir]

Correct.

…

On Wed, May 18, 2022, 4:38 PM Niel Dejonghe ***@***.***> wrote: @hasnain-tahir <https://github.com/hasnain-tahir> you mean you fixed it by using the workaround provided by @rednevals <https://github.com/rednevals> ? — Reply to this email directly, view it on GitHub <#22625 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK44H3FFQSHRYB74ASWQCV3VKTJEJANCNFSM5MEZISCQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jopelacroesus]

I have encountered this issue as well. Hoping for a fix

[PatriQ1414]

Any update on this?

[github-actions]

This functionality has been released in v4.21.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.