Bootstrap scheme for Go port

[William Reade]

On Thu, 2012-04-19 at 06:54 -0300, Gustavo Niemeyer wrote:
> 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.

I think I misunderstood the "respective release": if you're talking
about the local release it's fine, but it's just not going to be
possible to deploy juju 3.x.x code to a series whose latest version of
juju is 2.x.x. Er, this is obvious, isn't it? Sorry ;).

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

Thanks for the link; I was unaware of the special treatment of 0.x
(Clint described several incompatible changes in 0.x versions in the
other thread [0] and this threw me off ;)).

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

All fine: I'm not saying we shouldn't do it, just being explicit about
the tradeoffs we're choosing.

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

Yeah, I misspoke in response to a misread. Sorry.

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

It all hinges on what we consider to be 1.0.0 (I think that was proposed
to be the first go version in the other thread?). We've been talking
about incompatible minor versions, with no dissenting voices, and
there's some uncomfortable tension between "still being 0.x" and "not
wanting to mess with users" in the context of these plans. 

> > upgrade-juju --migrate`?
> 
> Maybe "upgrade --migrate --move-forward"? :-)

Probably sensible :).

> > I think this is a good use case for dev-mode as well.
> 
> Not sure about what you mean here.

Just that we'll need to be able to migrate released versions to dev
versions, before those dev versions become released versions, so we can
verify we can actually do the upgrades. Not meaningful until we have a
migration mechanism in place, ofc.

Did that help?

Cheers
William

[0] https://lists.ubuntu.com/archives/juju/2012-April/001437.html