gs_utils.py: use boto instead of google-api-python-client library so we can use .boto file credentia

gs_utils.py: use boto instead of google-api-python-client library so we can use .boto file credentials

Also adds these public functions:
- delete_file(bucket, path)
- upload_file(source_path, dest_bucket, dest_path)
and a self-test that exercises all functions.

BUG=skia:2732
R=jcgregorio@google.com

Committed: https://skia.googlesource.com/common/+/a6986a0

[epoger, 2014-07-13 22:34:39]

Joe (and others who may be interested)-- please see patchset 1.

Initially, I created this CL to add the self-test, not to switch away from the
google-api-python-client library.

But when I tried to do that, I ran into this problem: the self-test could not
read/write within the gs://chromium-skia-gm bucket, because of bucket
permissions.

And as I looked into it further, I found evidence that the
gs_access_key_id/gs_secret_access_key form of credentials we use are not
supported by Google Storage's JSON API (the one wrapped by
google-api-python-client).

I think it might be a good idea for us to explore a more modern form of
credentials... but in the meanwhile, I figured this change might help us get
closer to properly setting ACLs in Google Storage.

[jcgregorio, 2014-07-14 11:56:11]

Yeah, the boto file is for "Interoperable Access", which is there only for
interop with Amazon storage. Moving to OAuth 2.0 and away from boto is a good
long term plan.



On 2014/07/13 22:34:39, epoger wrote:
> Joe (and others who may be interested)-- please see patchset 1.
> 
> Initially, I created this CL to add the self-test, not to switch away from the
> google-api-python-client library.
> 
> But when I tried to do that, I ran into this problem: the self-test could not
> read/write within the gs://chromium-skia-gm bucket, because of bucket
> permissions.
> 
> And as I looked into it further, I found evidence that the
> gs_access_key_id/gs_secret_access_key form of credentials we use are not
> supported by Google Storage's JSON API (the one wrapped by
> google-api-python-client).
> 
> I think it might be a good idea for us to explore a more modern form of
> credentials... but in the meanwhile, I figured this change might help us get
> closer to properly setting ACLs in Google Storage.

[jcgregorio, 2014-07-14 12:10:32]

On 2014/07/14 11:56:11, jcgregorio wrote:
> Yeah, the boto file is for "Interoperable Access", which is there only for
> interop with Amazon storage. Moving to OAuth 2.0 and away from boto is a good
> long term plan.
> 
> 
> 
> On 2014/07/13 22:34:39, epoger wrote:
> > Joe (and others who may be interested)-- please see patchset 1.
> > 
> > Initially, I created this CL to add the self-test, not to switch away from
the
> > google-api-python-client library.
> > 
> > But when I tried to do that, I ran into this problem: the self-test could
not
> > read/write within the gs://chromium-skia-gm bucket, because of bucket
> > permissions.
> > 
> > And as I looked into it further, I found evidence that the
> > gs_access_key_id/gs_secret_access_key form of credentials we use are not
> > supported by Google Storage's JSON API (the one wrapped by
> > google-api-python-client).
> > 
> > I think it might be a good idea for us to explore a more modern form of
> > credentials... but in the meanwhile, I figured this change might help us get
> > closer to properly setting ACLs in Google Storage.

LGTM

[epoger, 2014-07-14 13:27:29]

The CQ bit was checked by epoger@google.com

[commit-bot: I haz the power, 2014-07-14 13:27:44]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-07-14 13:27:46]

Commit queue rejected this change because it did not recognize the base URL.
Please commit your change manually.

[epoger, 2014-07-14 13:29:30]

Committed patchset #1 manually as ra6986a0 (presubmit successful).