On Sun, Mar 30, 2014 at 5:44 PM, Kapil Thangavelu < [email protected]> wrote:
> > > > On Sun, Mar 30, 2014 at 4:17 PM, Ian Booth <[email protected]>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 <[email protected] >> >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 >> >> [email protected] >> >> Modify settings or unsubscribe at: >> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >> >> >> >> > >> > >> > >> > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
