On Mon, Mar 31, 2014 at 7:17 AM, 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. > > 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. 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. 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. > 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.) > +1 to William's suggestion of bootstrapping version.Current and then immediately upgrading. It feels a bit magical, but I think in a good way (it'll magically just work, all the time). 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. I'd be happy to take a look at this once HA is under control, unless someone else gets to it first. >> 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 >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
