Conversation continued from https://github.com/ansible/ansible-modules-extras/issues/1163
Rob,
I don’t see any difference in adding a CORS policy vs. adding a bucket policy and the latter remains part of the s3_bucket module. I needed CORS support for a project I’ve been working on and so I’ve filed a PR to add it to the bucket module. I can definitely be swayed if others feel that it should be separated out or if the bucket policy is separated out.
Respectfully,
Jaime
Hi Jamie,
The problem i have with the way you’ve implemented this is that there are no ansible parameters to configure the rule aside from just writing the XML yourself and passing that. It makes it more difficult for someone who isn’t too experienced in CORS to make use of this feature.
If there was a separate cors module with parameters such as allowed_header, allowed_method etc it may be clearer for someone to use.
I take your point that bucket_policy wasn’t done this way, however, the policy attributes are a lot more complex than a CORS rule and there are tools available from AWS to generate the policy for you.
Rob,
I like the simplicity of passing in my bucket’s CORS configuration as an XML string upon creation. It mirrors what’s expected by both Amazon’s API (http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUTcors.html) and boto, and the format is thoroughly documented by Amazon here: http://docs.aws.amazon.com/AmazonS3/latest/dev/cors.html. I had to follow the docs precisely because I was not experienced in CORS and I came away with a pretty good understanding of CORS and some great examples of how to format my XML. That being said, I don’t see a problem with having the option in s3_bucket to specify the entire cors configuration as XML, in addition to having a separate module (s3_cors_rule?) that allows adding/removing individual CORS rules to a bucket’s configuration in another way.