Publish location files for Mojo binaries uploaded from Chromium.

Publish location files for Mojo binaries uploaded from Chromium.

This CL is a companion to https://codereview.chromium.org/945423002, and will
allow a server app to serve apps that were uploaded to the Mojo bucket in GS
from Chromium without having to know anything about these apps in particular.

Committed: https://crrev.com/be126fc4bcb8bea3386fca5ff3bf03422443154c
Cr-Commit-Position: refs/heads/master@{#319070}

[blundell, 2015-02-24 16:12:57]

blundell@chromium.org changed reviewers:
+ jamesr@chromium.org

[jamesr, 2015-02-24 22:07:20]

https://codereview.chromium.org/956593003/diff/1/mojo/services/upload_service.py
File mojo/services/upload_service.py (right):

https://codereview.chromium.org/956593003/diff/1/mojo/services/upload_service...
mojo/services/upload_service.py:85: "_location")
what information are we uploading here that isn't already in the URL?

[blundell, 2015-02-25 13:07:31]

https://codereview.chromium.org/956593003/diff/1/mojo/services/upload_service.py
File mojo/services/upload_service.py (right):

https://codereview.chromium.org/956593003/diff/1/mojo/services/upload_service...
mojo/services/upload_service.py:85: "_location")
On 2015/02/24 22:07:19, jamesr wrote:
> what information are we uploading here that isn't already in the URL?

gs://mojo/services/<platform>/<service>_location is a file that stores the URL
at which the binary for <service> can be found. The purpose of this file is to
allow a server app to serve the current versions of Mojo apps (e.g., apps
published from the Mojo and Chromium repos) without having to be aware of the
details of which apps are published from where, under which conventions for path
constructions, etc: When the server app receives a request for <service>, it can
read the current location of the <service> binary from
https://storage.googleapis.com/mojo/services/<platform>/<service>_location and
then return a redirect to that location.

If you're asking "what information is in the contents of
gs://mojo/services/<platform>/<service>_location that isn't embedded in that
URL", the answer is the version. The reason I chose to store the URL of the
binary rather than e.g. just the version in this pointer file is to allow
flexibility in exactly where/with what path construction conventions binaries
are uploaded without requiring changes to the server app.

[jamesr, 2015-02-26 01:00:52]

It seems really strange to communicate with a server by uploading a bunch of
individual files to google storage.  Could you instead interact with the server
directly, or upload a file that lists a bunch of service locations?  Where does
the server code live?

[blundell, 2015-02-26 14:23:55]

I'm not at all tied to this approach; see my comments below for what led me to
using this mechanism and see what you think.

On 2015/02/26 01:00:52, jamesr wrote:
> It seems really strange to communicate with a server by uploading a bunch of
> individual files to google storage.  Could you instead interact with the
server
> directly, or upload a file that lists a bunch of service locations?  

Re: interacting with the server directly, I don't want to depend on the server
being online at the time of uploading apps.

Re: uploading a file that lists a bunch of service locations, there would be a
couple different ways to approach that:

(1) Have one file that lists all service locations, regardless of what repo they
come from. This would keep life easy on the server side but means that the
contents of this file would have to be carefully kept in sync when doing updates
from different repos.
(2) Have one file per repo. This means that different repos don't have to care
about each other; however, the server would have to know about multiple files to
fetch.

Where does
> the server code live?

https://codereview.chromium.org/953353002/

[jamesr, 2015-03-03 23:05:05]

Hmm, I guess this is OK but it seems likely that we'll want to configure the
server in a more sophisticated way down the line which will mean having a single
config file (or single per source of truth or something).

lgtm if you want to go with this for now.

[blundell, 2015-03-04 14:24:45]

Agreed that things will likely change in the long term. This will let us get
started serving things from Chromium to Mojo. Thanks!

[blundell, 2015-03-04 14:40:17]

The CQ bit was checked by blundell@chromium.org

[commit-bot: I haz the power, 2015-03-04 14:41:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/956593003/1

[commit-bot: I haz the power, 2015-03-04 15:01:22]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-03-04 15:01:56]

Patchset 1 (id:??) landed as
https://crrev.com/be126fc4bcb8bea3386fca5ff3bf03422443154c
Cr-Commit-Position: refs/heads/master@{#319070}