Bootstrap scheme for Go port

[Gustavo Niemeyer]

Hi there,

We're about to get started with Go-based bootstraps, and we have a few
ideas floating related to how to properly get the code in the server.
We're trying to solve a few issues upfront in the design, even if
we're only getting started with part of it. This is related to what
Clint has pointed out recently, but it doesn't really affect any of
the points he brought up right now. Instead, this is the design of a
solution that will solve his concerns in the future.

Let's start with a list of goals for what we're aiming at. The
solution must enable one to:

1. deploy using local code, and have the deployment running agents at
the same version of the local code; this is critical for development.

2. deploy on different architectures than the local machine

3. deploy with agent versions compatible with the local client, even
if the latest agent is not compatible with it

4. deploy in releases of Ubuntu older than the local machine, and have
them running the newest client that is compatible with the local
client (possibly newer than the latest distributed in the respective
release)

5. deploy in releases of Ubuntu newer than the local machine, and have
them running the newest client that is compatible with the local
client (possibly older than the latest distributed in the respective
release)

5. upgrade a deployment across compatible versions of juju

6. upgrade a deployment across incompatible versions of juju,
informing how to proceed


With these goals in mind, I propose the following scheme:

A. use semantic versioning and apply it on all releases

B. store the binaries of all releases in a well known public location,
with the scheme $PUBLIC/tools/juju-$MAJOR.$MINOR.$PATCH-$ARCH.tar.gz

C. on bootstrap find and use the largest toolset at $URL that has
toolset $MAJOR == client $MAJOR && toolset $ARCH == server $ARCH

D. alternatively, if a development flag is enabled, bootstrap will
first look for the toolset in the user's provider storage instead of
$PUBLIC, following the same scheme described; the client then uploads
the running binaries to the storage provider on bootstrap following
the same scheme

C. allow private deployments to optionally replace $PUBLIC; still
defaults to the well known public repository

E. implement "juju upgrade-juju" that looks at the configured $PUBLIC
and deploys the latest toolset $MAJOR == running $MAJOR

F. implement "juju upgrade-juju --patch" that looks at the configured
$PUBLIC and deploys the latest toolset $MAJOR & $MINOR == running
$MAJOR & $MINOR

F. implement "juju upgrade-juju --major" that allows moving $MAJOR
forward, but with more inconvenient consequences; for example, the
*whole* environment might be upgraded in lock-step, with an automatic
schema upgrade in between

This is the grand plan. Roger has some good progress on the ssh
proxying front that we're still looking at, so I propose we start by
implementing C & D this/next week.

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.