moto
moto copied to clipboard
framework for ResourceGroup list_group_resources
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.
@bblommers any thoughts on this?
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?
If you're willing to write the code for it 👍
@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.
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.
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'
}
, ...
]
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
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?
That sounds about right.