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

framework for ResourceGroup list_group_resources #2899

Open
caphrim007 opened this issue Apr 16, 2020 · 9 comments
Open

framework for ResourceGroup list_group_resources #2899

caphrim007 opened this issue Apr 16, 2020 · 9 comments
Labels

Comments

@caphrim007
Copy link
Contributor

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
Copy link
Contributor Author

@bblommers any thoughts on this?

@bblommers
Copy link
Collaborator

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
Copy link
Collaborator

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

@caphrim007
Copy link
Contributor Author

@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
Copy link
Collaborator

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
Copy link
Contributor Author

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
Copy link
Collaborator

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
Copy link
Contributor Author

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
Copy link
Collaborator

That sounds about right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants