What happened to pinned bootstrap

[Kapil Thangavelu]

On Sun, Mar 30, 2014 at 5:44 PM, Kapil Thangavelu <
kapil.thangavelu at canonical.com> wrote:

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


Replying to myself, to clarify this point.


> 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.
>
>
iotw, don't make users guess what will happen, which is currently what
happens and is terrifying for upgrades.

-k




>
>
>
>>
>> >
>> >
>> > 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/20140331/229a9b6b/attachment.html>