On Mon, Mar 31, 2014 at 5:16 AM, Andrew Wilkins < andrew.wilk...@canonical.com> wrote:
> On Mon, Mar 31, 2014 at 7:17 AM, Ian Booth <ian.bo...@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. >> >> 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. > Users get juju tools via a different mechanism than they get the client. (We search for updated tools, but they get their client via "apt-get install".) This is sort of Kapil's point for why it is nice to have the binaries sitting next to each other, because you get them via the same mechanism. Because our current bootstrap always tries the latest micro version, it isn't so much that they said "give me 1.17.7", and then get told their client is out of date. They just said "bootstrap me a working environment", and it breaks in a confusing way. (It doesn't even tell you anything about needing a newer version of the client, etc). > > On Sun, Mar 30, 2014 at 12:23 AM, John Meinel <j...@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.) >> > > +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. > > I think for the 2.* series that will be in Trusty, we need to be *much* more cautious about compatibility than we've been. I think this might make it a little bit easier, but it might also lead us into a false sense of "oh we can change this, because nothing will ever do X". If we want this behavior, we certainly need it before 2.0 releases, because otherwise 2.0.1 can't introduce that behavior because you still have to deal with 2.0.0 not having it. John =:->
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
