What happened to pinned bootstrap

[Andrew Wilkins]

On Mon, Mar 31, 2014 at 7:17 AM, Ian Booth <ian.booth at canonical.com> wrote:

>
> On 31/03/14 02:11, Kapil Thangavelu wrote:
> > sounds like a great case being made for --upload-tools by default.
> >
>
> --upload-tools does happen automatically on bootstrap, but only if no
> matching,
> pre-built tools are found. So, if a 1.19 client were used to bootstrap and
> only
> 1.18 tools were available, upload-tools would be done automatically.
>
> As John points out, tools matching is done based on major.minor version
> number.
> My understanding was that X.Y.Z should be compatible with X.Y.W where W !=
> Z. So
> 1.17.6 clients should have been compatible with 1.17.7 tools. If we break
> compatibility, then we should have incremented the minor version number.
> Or, in
> this case, given we didn't want to do that, ensure 1.17.7 tools were
> backwards
> compatible with 1.17.6 clients.
>
> Note that we used to just match tools on major version. This was correctly
> deemed unworkable, and so the move to major.minor matching was at the time
> considered to be sufficient so long as we coded for such compatibility. I
> think
> the core issue here was just a simple mistake and/or misunderstanding of
> the
> version compatibility policies in place. If the situation has highlighted
> the
> need for a change in policy, that's fine, but we then need to agree that
> we need
> to be stricter on tools matching.


So yes, it sounds like I misunderstood the compatibility requirements. I
guess I don't really see the value in it, so maybe someone can enlighten
me. Bootstrap is a cost to a single user for a once-off operation per
environment.

If the user is bootstrapping a new point release, I think it's reasonable
to require them to fetch the up-to-date client first. If they've got older
tools, then they can always upgrade to the newer ones anyway.

> On Sun, Mar 30, 2014 at 12:23 AM, John Meinel <john at arbash-meinel.com
> >wrote:
> >
> >> I thought at one point we were explicitly requiring that we bootstrap
> >> exact versions of tools (so juju CLI 1.17.2 would only bootstrap a
> 1.17.2
> >> set of tools). We at least did 1.17 will only bootstrap 1.17, but
> looking
> >> at the code we still always deploy the latest 1.17 (which broke all the
> >> 1.17 series of CLI because 1.17.7 has an incompatible required flag).
> >>
> >> There is an argument that we can't get away with such a thing in a
> stable
> >> series anyway, so it isn't going to be a problem. Mostly, though, I had
> >> thought that we did exact matching, but I can see from the code that is
> >> clearly not true.
> >>
> >> Would it be very hard to do so? I think William had a very interesting
> >> idea that CLI bootstrap would always only bootstrap the exact version of
> >> tools, but could set the AgentVersion to the latest stable minor
> version,
> >> so it essentially bootstraps and then immediately upgrades. (With the
> big
> >> benefit that the upgrade process to migrate from old versions to new
> >> versions gets run.)
>

+1 to William's suggestion of bootstrapping version.Current and then
immediately upgrading.
It feels a bit magical, but I think in a good way (it'll magically just
work, all the time).

I don't think it'd be terribly difficult. We already filter tools on
major.minor. So we should just then look for the greatest version of tools
<= version.Current (maybe warning if !=), and set agent-version to the
greatest version of tools > version.Current.
I'd be happy to take a look at this once HA is under control, unless
someone else gets to it first.

>> This could be a distraction from the other stuff we're working on, but it
> >> doesn't look that hard to implement, and would avoid some of these
> >> semi-accidental breaking of old tools.
> >>
> >> John
> >> =:->
> >>
> >> --
> >> Juju-dev mailing list
> >> Juju-dev at lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >>
> >>
> >
> >
> >
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140331/411b645d/attachment.html>