On each update, export variables that are all about where and when the update came from github

STARPHLEET_DEPLOY_TIME
STARPHLEET_DEPLOY_SHA
STARPHLEET_DEPLOY_GITURL

Currently the ships check in their address information into the HQ, as this is (most frequently in our current deployment) almost never useful I say we drop this behavior or fix it. One of this things is easier to do than the other, vote?

We do need to have an address before we can take any action, but this seems like a pretty slow bit. I've had trouble with Docker racing here, trying to run buildpacks before the network was really 'ready', which is what led to this script existing. But it should be possible to make this be a lot faster -- or maybe event driven from upstart?

just tee the actual service run to syslog and pop in some logger events to indicate progress on service builds

If there is a Makefile, just run make. Up to folks to have a smart first target by default, or they can specify a ${MAKE_TARGET} and that will be 'made'.

This should be run at the end of the buildpack sequence, right before the /start script generation.

openssl x509 -noout -in ssl/crt -dates

If a service fails to deploy, its container is torn down and it immediately rebuilt. If the service continues to fail, starphleet will keep tearing it down. It doesn't allow you a chance to hop onto the container to diagnose the problem and it's obviously wasting system resources going nuts trying to rebuild dead containers.

In the most extreme case recently encountered, nginx died which prevented starphleet from verifying services were healthy and it began to destroy/build all of the services deployed.

I'm on my Mac and want to query and inspect my phleet, but starphleet itself isn't appropriate to install on the Mac -- no upstart, LXC, etc.

By analogy, when you 'install Heroku' -- you don't, just just install the command line tools.

need some starphleet equivalent of foreman that will:

-run on my mac
-run buildpacks (this might be nasty, or require OSX versions)
-let me simply debug, in particular services like pi
-not make me commit/push, this is a needless step when debugging

saves the reloading of npms and gems and such. a global cache 'can' work, but it is my bet that we need a per order cache directory

PORT is being injected into nginx config verbatim. If you do this in the orders, .env or .starphleet:

export PORT='4444'

nginx will croak and report "invalid port in upstream "10.0.3.192:'4444'". Since nginx is down, so is all of starphleet.

saves folks from worrying about it...

Way more useful to have a starphleet cli come back with status and logs.

Just like I did on pi, need it in the manual.

prevents a flat spin, and allows for faster restart of a crashed service. seems like hashing the environment 'stack' of files along with the git sha of the ordered service

switching the #branch syntax can get a bit stuck

put in an order dir name, get out the hashes and containers so you can tell what is going on