aws/s3_bucket: Expose region + hosted zone ID

[radeksimko]

This is likely related to #1738, it can either be done in that PR, or separately once that PR is merged.

Some resources (probably should go into code as a hard-coded map):
http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_website_region_endpoints

This will be necessary for managing Route 53 ALIAS records pointing to S3 buckets.

cc @justincampbell

[justincampbell]

@radeksimko would the website_endpoint attribute that #1738 adds be sufficient, instead of exporting the region?

The zone ID is interesting.

[radeksimko]

@justincampbell Basically I think that the best way to approach the problem would be to change websiteEndpoint(s3conn *s3.S3, d *schema.ResourceData) to getWebsiteEndpointUrl(bucket, region string), i.e. refactor all location/region related logic outside of this function.
Then you can create a new function, e.g. getHostedZoneId(region string) which won't do anything more complicated than just map lookup and finally export the output.

[radeksimko]

And in that case ^ region may not be necessary, but I would export it anyway, if we allow creating buckets in different regions in the future (not just in the region coming from provider).

[justincampbell]

👍 I'll either do it in that PR or open a new right after, within a few days

[justincampbell]

Done in master...justincampbell:s3-region-zone

Either need to wait for feedback on aws/aws-sdk-go#222, or add it to Terraform temporarily.

[justincampbell]

@radeksimko aws/aws-sdk-go#222 was rejected. I don't think this logic belongs in TF, but I'd like others to chime in.

[radeksimko]

Hm, that sucks... but I still believe that letting user to look for this in the official AWS documentation is a bad approach.

[radeksimko]

Worst case scenario, we can at least link to the documentation from the route53_record ALIAS section.

[phinze]

While I agree it doesn't ultimately belong in TF, I'd toss my vote in for UX over cleanliness here and say we include the metadata. Terraform already holds knowledge of things like historically common config env variables for user benefit, and I don't think it's too much of a stretch to consider this mapping to be in the same arena.

That being said, if it's metadata we expect to change more than, say, once every 1-2 years, then perhaps we throw our hands up.

[justincampbell]

Done!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.