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

Feature Request: Support for Google Cloud Storage #1981

Closed
jimconner opened this issue May 15, 2015 · 12 comments
Closed

Feature Request: Support for Google Cloud Storage #1981

jimconner opened this issue May 15, 2015 · 12 comments

Comments

@jimconner
Copy link

It would be really great if you could add support for provisioning buckets using GCS - Although we're able to use a local-exec provisioner to call gstool for creating buckets, it would be great if Terraform could handle it directly through the google provider.

@dhilton
Copy link
Contributor

dhilton commented May 20, 2015

Hey! So @mtekel and I are going to have a go at adding this to the DSL for the google provider. Our intention is to implement the DSL according to the S3 schema.

  • name - the name of your bucket, conforming to Google Cloud Storage rules around naming buckets.
  • location - maps to one of the Google Cloud Storage service locations (defaults to US)
    • 'ASIA' - Asia
    • 'EU' - European Union
    • 'US' - United States
  • acl - maps to one of the predefined ACL strings for Google Cloud Storage:
    • 'private'
    • 'project-private'
    • 'public-read'
    • 'public-read-write
    • 'authenticated-read'

The created bucket will export the following variables:

  • id - The name of the bucket.
  • location - The Google Cloud Storage location of the bucket.

We intend to default all buckets to the standard storage.

Thus to create a bucket called 'foobar':

resource "google_storage_bucket" "img-store" {
    bucket = "foobar",
    acl = "public-read",
    location = "EU",
}

@sparkprime sparkprime self-assigned this May 21, 2015
@sparkprime
Copy link
Contributor

Heh when I self-assigned this, github only then showed me your message from a day ago. Guess I shouldn't keep tabs open this long. :)

@sparkprime sparkprime removed their assignment May 21, 2015
@sparkprime
Copy link
Contributor

Have you considered supporting the full BucketAccessControls semantics? I don't mind helping with this. I'd rather not see the field 'acl' repurposed to the predefined ACL strings, although it may be a good idea if using the full acl is too verbose, in which case we can call it predefined_acl or something like that.

@dhilton
Copy link
Contributor

dhilton commented May 21, 2015

We've got a branch locally coming hopefully tomorrow morning (GMT) - we haven't tackled the website operations nor some of the lower level ACL stuff - just the canned ones to create feature parity with the S3 provider (that was the scope of our internal story on this) - be great to get you to review the pull request and then add in some of the bits we didn't pick up specifically around updates such as change of ACL to existing buckets. The standard storage api (v1) is a bit short on examples around how you apply an ACL to a bucket, would you use this patch command?

(https://github.com/google/google-api-go-client/blob/master/storage/v1/storage-gen.go#L1820)

Happy to redefine the acl to predefined_acl will change in our local branch before pushing live.

@sparkprime
Copy link
Contributor

SGTM. Yes, you can simply use patch to update either low level acls inline with the bucket resource, or you can specify a different predefinedAcl in the query (but not both).

Note that you cannot delete a bucket unless it is empty, and deleting everything in it is a bit hairy because of eventual consistency and concurrent updates to the bucket. So, it's not clear to me how much we should help the user there. Maybe we can just force them to empty their own bucket. Any idea what the terraform s3 bucket resource does?

@jimconner
Copy link
Author

As of earlier today, Terraform now supports a force options to clean out the bucket before deletion... #1977

@sparkprime
Copy link
Contributor

Ok we should probably do the same thing.

@dhilton
Copy link
Contributor

dhilton commented May 24, 2015

So, apologies for the late reply, got caught by the force_destroy implementation.

The pull request can be found here:
#2060

I think the acceptance tests could do with a test case to cover the force_destroy option but otherwise I'm happy.

@sparkprime
Copy link
Contributor

Ok, will look on Tuesday, bank holiday over here in the states :)
On May 24, 2015 4:08 PM, "Dan Hilton" [email protected] wrote:

So, apologies for the late reply, got caught by the force_destroy
implementation.

The pull request can be found here:
#2060 #2060

I think the acceptance tests could do with a test case to cover the
force_destroy option but otherwise I'm happy.


Reply to this email directly or view it on GitHub
#1981 (comment)
.

@dhilton
Copy link
Contributor

dhilton commented Jun 3, 2015

As the pull request has been merged, can we close this issue now?

@sparkprime
Copy link
Contributor

Fixed in #2030

@ghost
Copy link

ghost commented May 2, 2020

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.

@ghost ghost locked and limited conversation to collaborators May 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants