Bootstrap scheme for Go port

[William Reade]

On Wed, 2012-04-18 at 20:26 -0300, Gustavo Niemeyer wrote:
> 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)

I think we may need to be a little stricter here: ie you *cannot* deploy
to a series whose latest released juju version is incompatible with the
client.

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

I think we might need to match $MAJOR.$MINOR rather than just $MAJOR, it
the plan to handle incompatible changes with $MINOR bumps still holds.

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

1) This potentially restricts the arches we can deploy to in dev mode,
which feels like it won't be a big deal until it suddenly is because
there's (say) some weird bug on ARM. I suppose we'll be ok if we always
cross-compile to, and upload, every arch, when in dev mode...

2) I don't get the "first look for the toolset in the user's provider
storage" bit. If I [build, bootstrap, destroy-environment, write new
code, bootstrap] I don't want the old code in the provider storage to be
used on the second bootstrap.

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

Wouldn't this be $MAJOR, $MINOR, $PATCH, similarly to above?

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

Similarly, I think this is a $MAJOR, $MINOR case; maybe `juju
upgrade-juju --migrate`?

I think this is a good use case for dev-mode as well.

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