Because of the hg->git switch and the switch to Go 1.4, which requires
bootstrapping for building from source:
-master now requires an env with a working Go to build builder (instead of
building go tip from source), and master does not monitor changes to the go
tree anymore.
-builder gets Go1.4.1 from the binary tarball (instead of building from
source), and does not build go tip anymore (nor does it run tests with
it).
Keeping it alive properly was not deemed worth the trouble since we plan
on replacing it with a new builder based on the same tools used for the
Go builders.
Change-Id: Idd0864350b27b6523675006f00719fba2d6fc72f
This change makes gce/create.go generate a self-signed certificate
with the hostname from the -hostname argument and upload it to GCS
before creating a new camlistore instance.
It also makes camlistored use baseURL to figure out the hostname
when generating its self-signed certificate.
Change-Id: I64f85853dab34a7ce95e5d5997e58f2e5da43496
Additional check to prevent b bad imports and un-go-fmt'd code
from sneaking in.
If users don't run tests, it will break the builder.
Change-Id: I95c74724aac68d915aa5195b6d8fcb78f92349e0
Use systemd/CoreOS instead of supervisor,
Less InnoDB memory,
No snapshots,
unrelated to Docker image: keep data files on CoreOS /var/lib/mysql-camli so
they persist across reboots.
Change-Id: Ib903c386fb3e2df0b7cf2d3eb466290f2b16f94b
I think I'm not using systemd correctly here. Things get very unhappy
if I reboot CoreOS: the Docker container named 'db' already exists, things keep
flapping up and down (not waiting for their dependencies), etc.
Maybe I need to register stop actions too.
Change-Id: I75ac3e965c03df4f7f3938ff13c66f137948bf4d
The machine now boots with a new pair of cooperating systemd units:
1) cam-journal-gatewayd.service: a copy of the systemd-journal-gatewayd service,
which runs an HTTP interface to the systemd journal.
2) cam-journal-gatewayd.socket: a unix socket listener listening on unix
socket /run/camjournald.sock. Incoming connections will forward to 1).
Then the camlistored.service unit running camlistored under Docker now
passes -v /run/camjournald.sock:/run/camjournald.sock to make that unix socket
available to the Docker container.
Then in camlistored, a new handler at /debug/logs (wrapped in auth
checks) then opens that socket and makes an HTTP request to it,
copying its response (of log lines) back to the browser.
This will ease debugging, letting people only use their browser to
debug (or send logs to the Camlistore developers more likely), rather
than sshing in to CoreOS and learning CoreOS and systemd arcana.
Change-Id: Icd5967ae7e9946d36229bdbc5d37644a11ee5e9f
I'm hoping this will help with our first test suite run (Go1) which
is often failing at the test trying to hit http://localhost:3179/ui
Change-Id: I972072ebc27b7a59136a90532000ca7e9d58a471
Because if e.g. 'devcam test' is the current child process, we want it to be
able to catch the signal and kill its own child too.
Change-Id: I3e3c9c10c8d7f5d793c98b604baf8df56608003e
Brad Fitzpatrick