aws / aws-cli

Universal Command Line Interface for Amazon Web Services
Other
15.55k stars 4.13k forks source link

ram: could not get pending status ram resource shares #8951

Open tangr opened 1 month ago

tangr commented 1 month ago

Describe the bug

aws ram get-resource-shares --resource-owner OTHER-ACCOUNTS could not get PENDING status ram share resources, just shows up ACTIVE status

{
    "resourceShares": [
        {
            "resourceShareArn": "arn:aws:ram:::resource-share",
            "name": "",
            "owningAccountId": "",
            "allowExternalPrincipals": true,
            "status": "ACTIVE",
            "creationTime": "2023-",
            "lastUpdatedTime": "2023-",
            "featureSet": "STANDARD"
        }
    ]
}

Even explicitly specifying PENDING status with:

aws ram get-resource-shares --resource-owner OTHER-ACCOUNTS --resource-share-status PENDING

{
    "resourceShares": []
}

And after I accepted the pending status ram share resource on console, it will shows up since the status of ram share resource is ACTIVE.

Regression Issue

Expected Behavior

show all status share resources on the ram:get-resource-shares api.

Current Behavior

Only show "ACTIVE" resources, or FAILED? not all resources.

Reproduction Steps

create ram share resources, but not accept on the target account.

Possible Solution

No response

Additional Information/Context

No response

CLI version used

aws-cli/2.9.13 Python/3.9.11

Environment details (OS name and version, etc.)

Darwin/23.1.0 exe/x86_64 prompt/off

tim-finnigan commented 1 month ago

Thanks for reaching out. The get-resource-shares command calls the underlying GetResourceShares API, so these results are coming from the AWS RAM API. When I tried creating a resource share, it almost immediately would go into ACTIVE state.

Are you trying to list pending invitation resources? Because in that case you'd want to use the list-pending-invitation-resources command. Otherwise could you tell us more about your use case?

Also version 2.9.13 is very old — the latest version is 2.17.60 per the CHANGELOG. Can you update to a more recent version in order to access the latest changes/fixes?

tangr commented 1 month ago

HI @tim-finnigan , thanks for your quickly response. I know it's under api. "it almost immediately would go into ACTIVE state." in it's action, will need to accept manually on console, but the console user may do not have enough permissions to accept it.

"Otherwise could you tell us more about your use case?" The usage scenario was under IAC, see as follows on pulumi/terraform.

https://www.pulumi.com/registry/packages/aws/api-docs/ram/getresourceshare/

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/ram_resource_share

And what I mean is the actual behavior is inconsistent with documentation, since the manual supports all Valid Values: PENDING | ACTIVE | FAILED | DELETING | DELETED resourceShareStatus

tim-finnigan commented 1 month ago

Thanks for following up. When testing this, the behavior I observed is that the resource share almost immediately went into an active state, so it wouldn't be in PENDING long enough to return that status via the API. Is that the behavior you're seeing? If you could share your debug logs (with any sensitive info redacted) by adding --debug to the command, then we can see what exactly the API response is.

tangr commented 1 month ago

HI @tim-finnigan , Sorry for the late reply, I didn't understand "the behavior I observed is that the resource share almost immediately went into an active state". Is it because your account under the organization and auto-accepted?

I think the accept should be accepted by manual. See attached.

img_v3_02ff_a6564bb2-977e-45bb-8f7f-334e99a129ag

but aws ram get-resource-shares --resource-owner OTHER-ACCOUNTS --resource-share-status PENDING

{
    "resourceShares": []
}
tim-finnigan commented 3 days ago

Thanks for following up — can you share your debug logs when running this command? You can get these by adding --debug to the command, and you can redact any sensitive information. The logs will show us the raw API response, which we can share with the service API team to help with further investigation of this issue.