On Fri, Apr 18, 2014 at 11:34 AM, Aaron Bentley <aaron.bent...@canonical.com > wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 14-04-18 06:28 AM, William Reade wrote: > > As for automatically upgrading: it's clearly apparent that there's > > a compelling case for not *always* doing so. But the bulk of patch > > releases *will* be server-side bug fixes, and it's not great if we > > generally fail to deliver those to casual users. > > I think that users should upgrade their clients in order to get bug > fixes. I think that users who don't upgrade their client are > expecting to get a lock-down experience, bugs and all. > > And how does that work with multi-user environments? Divergence is inevitable. > I don't think it's a good idea to default to deploying untested > software combinations, especially when using a tested software > combination will give a superior experience (i.e. client-side bug fixes). > We need better client api compatibility on minor versions. The exception is bootstrap for which exact match seems reasonable for *dev* versions. For stable versions we should be compatible across micro releases and testing the same, --version still seems good for users who want exact behavior/reproduction. > Even though you don't intend to introduce incompatibilities with old > clients in patchlevel updates, we're human and mistakes happen. CI > found lots of compatibility-breaking mistakes in the 1.17 series, and > I'm sure there were many more that were caught by code review and > juju-core's unit tests. > The way to be certain we don't introduce such incompatibilities is > testing with every patchlevel of the client, and that scales an > already-big workload linearly with the number of patchlevels. > for stable i think we need to go there, client versions across multiple clients and server versions will diverge across a stable series. Afaik we don't throw incompatibility flags/errors for older clients using 1.16 api against 1.18 api servers, but perhaps we should. To me a followup to that is to distribute binaries (static link) for the client as well so that people can get a newer client version as needed for their platform. > > There is value in using the latest patchlevel of the agent code. > There is risk in using untested client/agent combinations. It is hard > to weigh one against the other, and I say we don't have to-- we can > get the value without introducing the risk by upgrading the client. > > > > I'm inclined to go with (1) a --version flag for bootstrap, > > accepting only major.minor >= client tools and (2) a --dry-run flag > > for upgrade-juju (with the caveat that you'd need to pass its > > result in as --version to the next command, because new tools > > *could* be published in the gap between the dry-run and the, uh, > > wet one). Aaron, even though this doesn't promote your use case to > > the default, I think this'll address your issues; confirm? > > - --version would be an improvement, but we have a workaround, so it's > not /that/ important. It's really the users I'm thinking of, the ones > who care about reproducibility. I'd honestly rather have > - --bootstrap-host, because the lack of it is making our testing of the > manual provider a bit weird. > > Aaron > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJTUUYPAAoJEK84cMOcf+9h1l8IAJTlK7+6bhoAGSmD0uVvFjmN > XjqO26yQcQT+YNBLK5cNt2L6/nFmUUjLg9B1XA/y4rX6zTGUKKk9Ge1iyrfWRXf7 > ZQwWHgsMIKxTmVak9x12ack/0PQQ4/D8qoXcM5mVRDCyXJx+zVDnGSw7Cfq+5Td7 > cL79xrJb9Eakhw4AUzDnW7MGMIlQQIFbkMpRoO5YBhSLN+DCf8mpXRapCKGVwxf6 > oLBarulsDGuolE8641wz39vraYbOpVWZG6NVtK7hYSVjyF689rt1uitJD79ebDGc > zhoKNBdGQQbDceORfK9wxQcK5072XwzZpIQTaQAPioqJ7BJQ+SL7RWksZdraVTU= > =Fb/3 > -----END PGP SIGNATURE----- > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
