<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 31, 2014 at 7:17 AM, Ian Booth <span dir="ltr"><<a href="mailto:ian.booth@canonical.com" target="_blank">ian.booth@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><br>
On 31/03/14 02:11, Kapil Thangavelu wrote:<br>
> sounds like a great case being made for --upload-tools by default.<br>
><br>
<br>
</div>--upload-tools does happen automatically on bootstrap, but only if no matching,<br>
pre-built tools are found. So, if a 1.19 client were used to bootstrap and only<br>
1.18 tools were available, upload-tools would be done automatically.<br>
<br>
As John points out, tools matching is done based on major.minor version number.<br>
My understanding was that X.Y.Z should be compatible with X.Y.W where W != Z. So<br>
1.17.6 clients should have been compatible with 1.17.7 tools. If we break<br>
compatibility, then we should have incremented the minor version number. Or, in<br>
this case, given we didn't want to do that, ensure 1.17.7 tools were backwards<br>
compatible with 1.17.6 clients.<br>
<br>
Note that we used to just match tools on major version. This was correctly<br>
deemed unworkable, and so the move to major.minor matching was at the time<br>
considered to be sufficient so long as we coded for such compatibility. I think<br>
the core issue here was just a simple mistake and/or misunderstanding of the<br>
version compatibility policies in place. If the situation has highlighted the<br>
need for a change in policy, that's fine, but we then need to agree that we need<br>
to be stricter on tools matching.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
> On Sun, Mar 30, 2014 at 12:23 AM, John Meinel <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>>wrote:<br>
><br>
>> I thought at one point we were explicitly requiring that we bootstrap<br>
>> exact versions of tools (so juju CLI 1.17.2 would only bootstrap a 1.17.2<br>
>> set of tools). We at least did 1.17 will only bootstrap 1.17, but looking<br>
>> at the code we still always deploy the latest 1.17 (which broke all the<br>
>> 1.17 series of CLI because 1.17.7 has an incompatible required flag).<br>
>><br>
>> There is an argument that we can't get away with such a thing in a stable<br>
>> series anyway, so it isn't going to be a problem. Mostly, though, I had<br>
>> thought that we did exact matching, but I can see from the code that is<br>
>> clearly not true.<br>
>><br>
>> Would it be very hard to do so? I think William had a very interesting<br>
>> idea that CLI bootstrap would always only bootstrap the exact version of<br>
>> tools, but could set the AgentVersion to the latest stable minor version,<br>
>> so it essentially bootstraps and then immediately upgrades. (With the big<br>
>> benefit that the upgrade process to migrate from old versions to new<br>
>> versions gets run.)<br></div></div></blockquote><div><br></div><div>+1 to William's suggestion of bootstrapping version.Current and then immediately upgrading.</div><div>It feels a bit magical, but I think in a good way (it'll magically just work, all the time).<br>
</div><div><br></div><div>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.</div>
<div>I'd be happy to take a look at this once HA is under control, unless someone else gets to it first.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">
>> This could be a distraction from the other stuff we're working on, but it<br>
>> doesn't look that hard to implement, and would avoid some of these<br>
>> semi-accidental breaking of old tools.<br>
>><br>
>> John<br>
>> =:-><br>
>><br>
>> --<br>
>> Juju-dev mailing list<br>
>> <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
>> Modify settings or unsubscribe at:<br>
>> <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
>><br>
>><br>
><br>
><br>
><br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</div></div></blockquote></div><br></div></div>