Bootstrap scheme for Go port

[Kapil Thangavelu]

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


Looks great, we need this. Two comments though, since the version is 
effectively the same through the cluster (minus errors) what do we gain by not 
just using a single integer ala charms, ie. even minor version code drift is 
potentially problematic. Second, the upgrade protocol for agents and schema 
migration capability is unspecified. I was thinking moving agents to stopped 
(but alive), download and extract code, wait on reboot node, schema upgrade 
(spec'd as code against rev), and agent reboot.

cheers,

Kapil