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

AWS AppStream FleetStackAssociation destroy not working #1966

Closed
ejfine opened this issue May 5, 2022 · 9 comments
Closed

AWS AppStream FleetStackAssociation destroy not working #1966

ejfine opened this issue May 5, 2022 · 9 comments
Assignees
Labels
awaiting-upstream The issue cannot be resolved without action in another repository (may be owned by Pulumi). kind/bug Some behavior is incorrect or out of spec resolution/fixed This issue was fixed
Milestone

Comments

@ejfine
Copy link

ejfine commented May 5, 2022

What happened?

I'm spinning up a Stack, Fleet, and StackFleetAssociation. That works fine to spin it up, but when I try and destroy it, it won't tear down because the Stack & Fleet can't be deleted while still associated, but the Association isn't being deleted. I even explicitly added depends_on, although that seems like in theory it should be superfluous because the stack and fleet names are already required arguments to the Association.

Steps to reproduce

from pulumi import export
from pulumi import ResourceOptions
from pulumi_aws import appstream
from pulumi_aws import iam




fleet = appstream.Fleet(
        append_resource_suffix("auto-eng"),
        compute_capacity=appstream.FleetComputeCapacityArgs(
            desired_instances=1,
        ),
        description="Fleet to control the AppStream for Automation Engineering",
        display_name="automation-engineering",
        enable_default_internet_access=False,  
        fleet_type="ON_DEMAND",
        idle_disconnect_timeout_in_seconds=60,
        image_arn=REDACTED,
        instance_type="stream.standard.large",
        max_user_duration_in_seconds=7200,
        vpc_config=appstream.FleetVpcConfigArgs(subnet_ids=[appstream_subnet_id]),
    )

    appstream_stack = appstream.Stack(
        append_resource_suffix("auto-eng"),
        application_settings=appstream.StackApplicationSettingsArgs(
            enabled=True,
            settings_group=append_resource_suffix("auto-eng"),
        ),
        description="Tooling to write code to control robotic instruments.",
        display_name="Automation Engineering",
        storage_connectors=[
            appstream.StackStorageConnectorArgs(
                connector_type="HOMEFOLDERS",
            )
        ],
        user_settings=[
            appstream.StackUserSettingArgs(
                action="CLIPBOARD_COPY_FROM_LOCAL_DEVICE",
                permission="ENABLED",
            ),
            appstream.StackUserSettingArgs(
                action="CLIPBOARD_COPY_TO_LOCAL_DEVICE",
                permission="ENABLED",
            ),
            appstream.StackUserSettingArgs(
                action="FILE_UPLOAD",
                permission="ENABLED",
            ),
            appstream.StackUserSettingArgs(
                action="FILE_DOWNLOAD",
                permission="ENABLED",
            ),
            appstream.StackUserSettingArgs(
                action="PRINTING_TO_LOCAL_DEVICE",
                permission="DISABLED",
            ),
            appstream.StackUserSettingArgs(
                action="DOMAIN_PASSWORD_SIGNIN",
                permission="ENABLED",
            ),
            appstream.StackUserSettingArgs(
                action="DOMAIN_SMART_CARD_SIGNIN",
                permission="DISABLED",
            ),
        ],
    )
    appstream.FleetStackAssociation(
        append_resource_suffix("auto-eng"),
        fleet_name=fleet.name,
        stack_name=appstream_stack.name,
        opts=ResourceOptions(depends_on=[fleet, appstream_stack]),
    )

Expected Behavior

calling destroy destroys the stack

Actual Behavior

pulumi.automation.errors.CommandError: 
 code: 255
 stdout: Destroying (first-attempt):

 -  aws:appstream:Stack auto-eng--appstream--first-a deleting
 -  aws:appstream:Fleet auto-eng--appstream--first-a deleting
 -  aws:appstream:Fleet auto-eng--appstream--first-a deleting error: deleting urn:pulumi:first-attempt::appstream::aws:appstream/fleet:Fleet::auto-eng--appstream--first-a: 1 error occurred:
 -  aws:appstream:Fleet auto-eng--appstream--first-a **deleting failed** error: deleting urn:pulumi:first-attempt::appstream::aws:appstream/fleet:Fleet::auto-eng--appstream--first-a: 1 error occurred:
 -  aws:appstream:Stack auto-eng--appstream--first-a deleting error: deleting urn:pulumi:first-attempt::appstream::aws:appstream/stack:Stack::auto-eng--appstream--first-a: 1 error occurred:
 -  aws:appstream:Stack auto-eng--appstream--first-a **deleting failed** error: deleting urn:pulumi:first-attempt::appstream::aws:appstream/stack:Stack::auto-eng--appstream--first-a: 1 error occurred:
    pulumi:pulumi:Stack appstream-first-attempt  error: update failed
    pulumi:pulumi:Stack appstream-first-attempt **failed** 1 error

Diagnostics:
  aws:appstream:Stack (auto-eng--appstream--first-a):
    error: deleting urn:pulumi:first-attempt::appstream::aws:appstream/stack:Stack::auto-eng--appstream--first-a: 1 error occurred:
        * error deleting Appstream Stack (auto-eng--appstream--first-a-a53b37b): ResourceInUseException: Cannot delete stack auto-eng--appstream--first-a-a53b37b. This stack has fleets associated with it. Only stacks with no fleets associated with it can be deleted.

  pulumi:pulumi:Stack (appstream-first-attempt):
    error: update failed

  aws:appstream:Fleet (auto-eng--appstream--first-a):
    error: deleting urn:pulumi:first-attempt::appstream::aws:appstream/fleet:Fleet::auto-eng--appstream--first-a: 1 error occurred:
        * error deleting Appstream Fleet (auto-eng--appstream--first-a-7895ae2): ResourceInUseException: The fleet auto-eng--appstream--first-a-7895ae2 is associated with a stack. To delete the fleet, you must dissociate it from the stack.
        ```

### Versions used

`pulumi about` wanted me to log in, but we're self hosting.  here's `pip freeze`:

```Arpeggio==1.10.2
astroid==2.11.2
attrs==21.4.0
boto3==1.22.7
boto3-stubs==1.22.7
botocore==1.25.7
botocore-stubs==1.24.38
cattrs==22.1.0
cfgv==3.3.1
click==8.1.3
colorama==0.4.4
copier==6.0.0a9
dill==0.3.4
distlib==0.3.4
dunamai==1.11.1
exceptiongroup==1.0.0rc3
filelock==3.6.0
grpcio==1.43.0
iam-floyd==0.365.0
identify==2.4.12
importlib-metadata==4.11.3
iniconfig==1.1.1
isort==5.10.1
iteration-utilities==0.11.0
Jinja2==3.0.3
jinja2-ansible-filters==1.3.0
jmespath==1.0.0
jsii==1.57.0
lazy-object-proxy==1.7.1
MarkupSafe==2.0.1
mccabe==0.7.0
mypy==0.942
mypy-boto3-lambda==1.22.0.post1
mypy-boto3-s3==1.22.6
mypy-boto3-sts==1.22.0.post1
mypy-extensions==0.4.3
nodeenv==1.6.0
packaging==21.3
parver==0.3.1
pathspec==0.9.0
pep517==0.12.0
pip-tools==6.6.0
platformdirs==2.5.1
pluggy==1.0.0
plumbum==1.7.2
pre-commit==2.17.0
prompt-toolkit==3.0.29
protobuf==3.20.0
publication==0.0.3
pulumi==3.32.0
pulumi-aws==5.4.0
pulumi-aws-native==0.11.0
py==1.11.0
pydantic==1.9.0
pyenchant==3.2.2
Pygments==2.11.2
pylint==2.13.5
pyparsing==3.0.8
pytest==7.1.1
pytest-mock==3.7.0
pytest-pylint==0.18.0
pytest-randomly==3.11.0
python-dateutil==2.8.2
PyYAML==5.4.1
pyyaml-include==1.2.post2
questionary==1.10.0
s3transfer==0.5.2
semver==2.13.0
six==1.16.0
stdlib-utils==0.4.8
toml==0.10.2
tomli==2.0.1
typing_extensions==4.1.1
urllib3==1.26.9
virtualenv==20.14.1
wcwidth==0.2.5
wrapt==1.14.0
zipp==3.8.0```

### Additional context

_No response_

### Contributing

Vote on this issue by adding a 👍 reaction. 
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already). 
@ejfine ejfine added the kind/bug Some behavior is incorrect or out of spec label May 5, 2022
@Frassle
Copy link
Member

Frassle commented May 6, 2022

You don't happen to have a full pulumi program we could run to repro this? The snippet above is dependent on a load of variables that you've removed so can't actually be run.

@ejfine
Copy link
Author

ejfine commented May 6, 2022

this is possibly related to hashicorp/terraform-provider-aws#22625 (?). But I'm not sure.

other than the subnet and the image name (which I can't imagine would make a difference), is there anything else missing?

You could use this as the image name if you want a specific example "AppStream-WinServer2019-03-03-2022"

Here's the VPC/subnet. Although I've tried it with others and same issue.

vpc_cidr = '172.16.146.0/24'


    vpc = ec2.Vpc(
        append_resource_suffix(vpc_name),
        cidr_block=vpc_cidr,
        enable_dns_support=True,
    )
    appstream_subnet_cidr = '172.16.146.192/27'

    appstream_subnet = ec2.Subnet(append_resource_suffix("appstream"), vpc_id=vpc.id, cidr_block=appstream_subnet_cidr) 
    ```

@mikhailshilkov
Copy link
Member

@eli88fine I'm trying to run this program - how do I provide this image arn? I'm not super familiar with appstream... Thank you!

image_arn=REDACTED
``

@mikhailshilkov mikhailshilkov added the awaiting-feedback Blocked on input from the author label May 11, 2022
@ejfine
Copy link
Author

ejfine commented May 12, 2022

You can use image_name="AppStream-WinServer2019-03-03-2022"
instead of the ARN kwarg if you just need a generic image every AWS account has

@mikhailshilkov mikhailshilkov removed the awaiting-feedback Blocked on input from the author label May 17, 2022
@mikhailshilkov
Copy link
Member

Okay I was able to mostly repro this with the following program:

from pulumi import ResourceOptions
from pulumi_aws import appstream

fleet = appstream.Fleet(
    "auto-eng",
    compute_capacity=appstream.FleetComputeCapacityArgs(
        desired_instances=1,
    ),
    idle_disconnect_timeout_in_seconds=60,
    image_name="Amazon-AppStream2-Sample-Image-02-04-2019",
    instance_type="stream.standard.small",
)

appstream_stack = appstream.Stack(
    "auto-eng",
)
appstream.FleetStackAssociation(
    "auto-eng",
    fleet_name=fleet.name,
    stack_name=appstream_stack.name,
    opts=ResourceOptions(depends_on=[fleet, appstream_stack]),
)

pulumi destroy does delete the FleetStackAssociation but apparently this has no real effect and the association is still kept intact and I get an error ResourceInUseException: Cannot delete stack auto-eng-bla. This stack has fleets associated with it. Only stacks with no fleets associated with it can be deleted..

I believe it's a provider issue so I'll move it to pulumi-aws. I'm on the latest pulumi-aws 5.4.0.

@mikhailshilkov mikhailshilkov transferred this issue from pulumi/pulumi May 25, 2022
@mikhailshilkov mikhailshilkov added the needs-triage Needs attention from the triage team label May 25, 2022
@ejfine
Copy link
Author

ejfine commented May 25, 2022

Here's the workaround I found in the meantime, if other people run across this same problem (using the Pulumi Command plugin):

local.Command(
            self.resource_name("fleet-stack-association"),
            create=Output.all(fleet.name, appstream_stack.name).apply(
                lambda args: f"aws appstream associate-fleet --fleet-name {args[0]} --stack-name {args[1]}"
            ),
            delete=Output.all(fleet.name, appstream_stack.name).apply(
                lambda args: f"aws appstream disassociate-fleet --fleet-name {args[0]} --stack-name {args[1]}"
            ),
            opts=ResourceOptions(depends_on=[fleet, appstream_stack]),
        )

@stack72 stack72 added awaiting-upstream The issue cannot be resolved without action in another repository (may be owned by Pulumi). and removed needs-triage Needs attention from the triage team labels May 25, 2022
@zulizzi-cfg
Copy link

Just FYI, upstream issue (hashicorp/terraform-provider-aws#22625) has been resolved.

@ejfine
Copy link
Author

ejfine commented Jul 19, 2022

Great! Is there a specific minimum version of pulumi AWS that will use that patched version of terraform?

@stack72 stack72 added the resolution/fixed This issue was fixed label Sep 5, 2022
@stack72 stack72 self-assigned this Sep 5, 2022
@stack72 stack72 added this to the 0.77 milestone Sep 5, 2022
@stack72
Copy link
Contributor

stack72 commented Sep 5, 2022

This has been released as part of pulumi-aws v5.10.0 - thanks for the reminder here @zulizzi-cfg

@stack72 stack72 closed this as completed Sep 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting-upstream The issue cannot be resolved without action in another repository (may be owned by Pulumi). kind/bug Some behavior is incorrect or out of spec resolution/fixed This issue was fixed
Projects
None yet
Development

No branches or pull requests

5 participants