framework for ResourceGroup list_group_resources

[caphrim007]

While adding unit tests for my own code, I noticed that the list_group_resources method of the ResourceGroups service was not implemented.

Upon further investigation, due to the nature of the values returned by this method, it seems like it would operate in a way very similar to how the AWS ConfigQueryModel framework is implemented insofar as,

• the ConfigQueryModel class queries all of the backends that support its interface
• it returns the data in the form that AWS Config would return it.

ResourceGroups work in a similar manner. For example,

$ aws resource-groups list-group-resources --group-name foo --profile dev
{
    "ResourceIdentifiers": [
        {
            "ResourceArn": "arn:aws:sqs:us-east-1:123456789123:events-queue",
            "ResourceType": "AWS::SQS::Queue"
        }
    ]
}

Since there is an existing framework for AWS Configs (of where there are 2 backends which it supports; AWS::S3::Bucket and AWS::S3::AccountPublicAccessBlock) could either of the following be considered?

• Extension of this pattern to include similar for ResourceGroups (ie, a file like config.py, the concrete implementation of ConfigQueryModel, etc)
• Extension of the AWS ConfigQueryModel to also be used for ResourceGroups

The latter may not make sense though because the return values of the methods-to-implement would not align with what is done for resource groups.

Interested in any other thoughts and proposals as well.

[caphrim007]

@bblommers any thoughts on this?

[bblommers]

Hi @caphrim007, I don't have experience with either service, so I don't think I'm best placed to have an opinion on this.

@mikegrima I believe you have done some work on the Config service - any thoughts on this?

[mikegrima]

If you're willing to write the code for it 👍

[caphrim007]

@mikegrima if it were to be implemented, do you have any recommendations for doing such? I was just going to copy what was done for the Config classes and change attributes, but wasn't sure if that would be frowned on.

[mikegrima]

I don't know much about resource groups. Is it basically just a mapping of ARN and Resource Type? If so, then it's very similar to what I did for Config only you shouldn't need to modify each resource type that you need.

[caphrim007]

Correct, a basic payload looks like this

{
    "ResourceIdentifiers": [
        {
            "ResourceArn": "arn:aws:ec2:us-east-1:XXXXXXX:elastic-ip/eipalloc-0ea111111c18",
            "ResourceType": "AWS::EC2::EIP"
        },
        {
            "ResourceArn": "arn:aws:ec2:us-east-1:XXXXXXX:elastic-ip/eipalloc-0fdd1c22221b13",
            "ResourceType": "AWS::EC2::EIP"
        },
....
}

The way Configs are done (where they are expanded using the service backends) looks very similar. The ResourceGroups just have different fields than the ConfigQuery defines

ConfigQuery below

            [
                {
                    'type': 'AWS::The AWS Config data type',
                    'name': 'The name of the resource',
                    'id': 'The ID of the resource',
                    'region': 'The region of the resource -- if global, then you may want to have the calling logic pass in the
                               aggregator region in for the resource region -- or just us-east-1 :P'
                }
                , ...
            ]

[mikegrima]

Yup, that seems right. You'll need to do something similar to what was done here: https://github.com/spulec/moto/blob/master/moto/config/models.py#L62

[caphrim007]

Thats what I thought. With that approach in mind, should I also create classes/modules similar to what was done for configs?

https://github.com/spulec/moto/blob/master/moto/config/models.py#L47

Where each resource would have to define, say, a resource_group file with the mentioned functions?

[mikegrima]

That sounds about right.