What happened to pinned bootstrap

[Aaron Bentley]

-----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.

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).

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.

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-----