<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Mar 30, 2014 at 5:44 PM, Kapil Thangavelu <span dir="ltr"><<a href="mailto:kapil.thangavelu@canonical.com" target="_blank">kapil.thangavelu@canonical.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Sun, Mar 30, 2014 at 4:17 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><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></blockquote><div><br></div></div><div>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. <br> </div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <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.<br> <div><div><br></div></div></blockquote><div><br></div></div><div>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.</div> <div><br></div><div>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. </div> </div></div></div></blockquote><div><br></div><div><br></div><div>Replying to myself, to clarify this point.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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. </div> <div><br></div></div></div></div></blockquote><div> </div><div>iotw, don't make users guess what will happen, which is currently what happens and is terrifying for upgrades.</div><div><br></div><div>-k</div><div><br> </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"> <div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> <div> <br> ><br> ><br> > On Sun, Mar 30, 2014 at 12:23 AM, John Meinel <<a href="mailto:john@arbash-meinel.com" target="_blank">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> >><br> >> 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" target="_blank">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> </div></div></blockquote></div></div></div><br></div></div> </blockquote></div><br></div></div>