Bootstrap scheme for Go port

[Gustavo Niemeyer]

On Thu, Apr 19, 2012 at 06:39, William Reade
<william.reade at canonical.com> wrote:
>> 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.

The juju in the deployed series is irrelevant here. If you have
concerns I'm not understanding, please bring them up in the proposed
solution so we can see how to fix them.

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

With semantic versioning (and in most versioning) incompatible changes
are not allowed in minor versions. Please see http://semver.org for
details.

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

Right, we can polish this further later, but this is the situation we
are in right now and for a while, the stated should be enough.

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

Yeah, that means we have to upload it again in development mode, but
the point made is that the server side still has to look somewhere,
and it's in the provider storage that it looks.

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

Hmm.. no? If you only allow upgrades when all three match, you'll
never upgrade, right? :-)

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

Ditto.

> upgrade-juju --migrate`?

Maybe "upgrade --migrate --move-forward"? :-)

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

Not sure about what you mean here.

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

-- I'm not absolutely sure of anything.