Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AppStream Fleet Timeout Instead of Create Error #20994

Closed
YakDriver opened this issue Sep 22, 2021 · 1 comment · Fixed by #21125
Closed

AppStream Fleet Timeout Instead of Create Error #20994

YakDriver opened this issue Sep 22, 2021 · 1 comment · Fixed by #21125
Labels
service/appstream Issues and PRs that pertain to the appstream service. service/ec2 Issues and PRs that pertain to the ec2 service.

Comments

@YakDriver
Copy link
Member

YakDriver commented Sep 22, 2021

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

In a Nutshell

The create waiter for AppStream fleet waits for the status to change from STARTING to something else. Unfortunately, AWS handles this slightly differently. If there are errors (e.g., the subnet configuration is bad), the status will remain STARTING for months (or, years, presumably) but AWS will provide FleetErrors. Thus, only waiting for an error or the status to change is not sufficient. The waiter must also check FleetErrors.

Terraform CLI and Terraform AWS Provider Version

Terraform v1.0.5
AWS v.3.60.0

Affected Resource(s)

  • aws_appstream_fleet

Raw AWS JSON Response

Notice Fleets[0].State and Fleets[0].FleetErrors below.

{
    "Fleets": [
        {
            "Arn": "arn:aws:appstream:us-west-2:012345678901:fleet/tf-acc-test-7548033492048225899",
            "Name": "tf-acc-test-7548033492048225899",
            "Description": "Description of a test",
            "ImageName": "Amazon-AppStream2-Sample-Image-02-04-2019",
            "ImageArn": "arn:aws:appstream:us-west-2::image/Amazon-AppStream2-Sample-Image-02-04-2019",
            "InstanceType": "stream.standard.small",
            "FleetType": "ON_DEMAND",
            "ComputeCapacityStatus": {
                "Desired": 1,
                "Running": 0,
                "InUse": 0,
                "Available": 0
            },
            "MaxUserDurationInSeconds": 1000,
            "DisconnectTimeoutInSeconds": 900,
            "State": "STARTING",
            "VpcConfig": {
                "SubnetIds": [
                    "subnet-0d9655566588b8115"
                ],
                "SecurityGroupIds": []
            },
            "CreatedTime": "2021-08-24T13:39:54.900000-04:00",
            "FleetErrors": [
                {
                    "ErrorCode": "SUBNET_NOT_FOUND",
                    "ErrorMessage": "The subnet(s) '[subnet-0d9655566588b8115]' does not exists. Please provide a valid subnet."
                },
                {
                    "ErrorCode": "INVALID_SUBNET_CONFIGURATION",
                    "ErrorMessage": "All provided subnets are invalid. Please provide a valid subnet ID that can be used."
                }
            ],
            "EnableDefaultInternetAccess": false,
            "IdleDisconnectTimeoutInSeconds": 70,
            "StreamView": "APP"
        }
    ]
}

Terraform Configuration Files

Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.

To reproduce, tweak the subnet configuration to be invalid.

resource "aws_subnet" "test" {
  count             = 2
  availability_zone = data.aws_availability_zones.available.names[count.index]
  cidr_block        = "10.0.${count.index}.0/24"
  vpc_id            = aws_vpc.test.id
}

resource "aws_appstream_fleet" "test" {
  name       = "Mitt-namn-är-Simon"
  image_name = "Amazon-AppStream2-Sample-Image-02-04-2019"

  compute_capacity {
    desired_instances = 1
  }

  description                        = "Det finns ingen ko på isen."
  display_name                       = "Fleetwood Mac"
  idle_disconnect_timeout_in_seconds = 70
  enable_default_internet_access     = false
  fleet_type                         = "ON_DEMAND"
  instance_type                      = "stream.standard.small"
  max_user_duration_in_seconds       = 1000

  vpc_config {
    subnet_ids = aws_subnet.test.*.id
  }
}

Expected Behavior

As soon as AWS returns an error, the Terraform AWS provider should stop waiting on the status and provide the error, rather than waiting until the timeout.

Actual Behavior

No error displayed, creation hung rather than failed, reached timeout although AWS returned the error relatively quickly.

Steps to Reproduce

  1. Tweak configuration above to have an invalid subnet
  2. terraform apply
  3. Wait for timeout.

References

@github-actions github-actions bot added service/appstream Issues and PRs that pertain to the appstream service. service/ec2 Issues and PRs that pertain to the ec2 service. labels Sep 22, 2021
@github-actions
Copy link

github-actions bot commented Jun 4, 2022

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 4, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
service/appstream Issues and PRs that pertain to the appstream service. service/ec2 Issues and PRs that pertain to the ec2 service.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant