Brad Fitzpatrick 7b6d1b1b28 all: remote buildlets ... This creates a mechanism for clients (such as cmd/release and cmd/gomote) to obtain buildlets via the coordinator. Previously cmd/release and cmd/gomote could only create GCE VMs themselves, and required the GCE project's credentials. In addition to the awkwardness of needing to hand out the GCE credentials, it also meant ARM and Darwin buildlets (which use the reverse buildlet pool) weren't usable. Instead, this creates a new auth mechanism where the coordinator is contacted over TLS with key pinning (the CA system isn't used) in the same way that the reverse builders already dialed into the coordinator, and then a "user build type" and hash are sent as the username and password. The same master key is used to sign user builder keys, and they always start with "user-". (which isn't a GOOS). Then the coordinator provides an API to create and list buildlets. They auto-expire after a duration and are auto-renewed upon use. The buildlet library (as used by cmd/release etc) then proxies HTTP requests via the coordinator to the backend buildlet. See doc/remote-buildlet.txt for protocol details. Change-Id: I12e27eae788fdd91927cb182b950893dc759f8e9 Reviewed-on: https://go-review.googlesource.com/11901 Reviewed-by: Andrew Gerrand <adg@golang.org>		2015-07-07 16:45:21 +00:00
..
remote-buildlet.txt	all: remote buildlets	2015-07-07 16:45:21 +00:00