What happened to pinned bootstrap

[Kapil Thangavelu]

On Sun, Mar 30, 2014 at 4:17 PM, 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.
>

On trunk it currently just falls back to the latest tools major/minor
version match found in streams afaics. (ie 1.17.8 trunk client bootstraps
1.17.7 env) which may or may not be compatible and is backwards version
movement, though it matches up with the major/minor match you write of.


>
> 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.
>
>
there's still a few issues with simplestreams vs upload-tools even when it
works perfectly. additional steps and maintenance for private clouds, zero
visibility into version chosen when upgrading juju (ie. no dryrun).
thankfully as of last week private clouds setup are publicly documented for
initial bootstrap.

still, all told, the simplicity of just use the binary i'm running is that
its incredibly transparent and obvious what the result will be and always
works, and i've basically hardwired it to avoid ambiguity. i know many of
us have spent a few hrs helping users debug tool issues. but perhaps this
is just the last step on the road to working reliably and transparently. in
that case, i'd suggest for dev versions we default to major/minor/micro
match, and stable can keep major/minor match or do the same, and never go
backwards on versions when bootstrapping. For the transparency aspect
having a flag/plugin/cli to find what version juju will pick for a given
env on bootstrap & upgrade would be good.

cheers,

kapil




>
> >
> >
> > 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.)
> >>
> >> 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
> >>
> >>
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140330/2df321b8/attachment-0001.html>