Bootstrap scheme for Go port

[Clint Byrum]

Excerpts from Gustavo Niemeyer's message of Wed Apr 18 16:26:10 -0700 2012:
> 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
> 

+1 on all reqs. This is great.

> 
> With these goals in mind, I propose the following scheme:
> 
> A. use semantic versioning and apply it on all releases
> 

+1 and +1 for using major version to signify backward incompatible
changes and odd/even for dev/stable.

> 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
> 

+1, I'd like to make clear though, I think only *clients* should
access this resource. They should pull the binary and push it into the
environment so that an environment is completely independent and can
operate without access to any public resources.

> 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.
> 

I love this plan. Thank you for putting it together. If there's anything
I can do to help, let me know.