Descriptionupgrade-juju: improvements
So, this started out as a quick branch to fix the versioning-related tests
in light of the change to dev versions. Quite a lot of the changes were
mechanical, by jujud.Upgrader and UpgradeJujuCommand demanded quite a lot
of careful thought and additional test coverage.
It should be noted that the dev versioning change made here is somewhat
cautious: it makes developiness contingent on (1) minor version oddity and
(2) build version existence. This is open to further discussion, and it will
be much easier to deal with further changes once this branch has landed.
The end result of my attempts to fix the various broken and/or untested
bits of the command was a rewritten command, with the following consequences
within the cmd/juju package.
* bootstrap now accepts --series instead of --fake-series.
* upgrade-juju also accepts --series.
* --series is only valid when used with --upload-tools on either command;
in each case, it clones the tools built for the host series such that
they are uploaded as the tools for all supplied series.
* when --series is omitted, --upload-tools will assume that tools should
be cloned for any of the following that are not the host series:
* precise (config.DefaultSeries), for which most charms are written;
* environment default-series, on which env machines will run.
* --upload-tools now forces the reported number of the built tools to be
the same as the current CLI tools (plus a build number); this is wrong,
in general, but it's consistently and mostly harmlessly so.
* if a --version param is passed to upgrade-juju --upload-tools, it
instead builds the current source and forces its reported number to
match the supplied version (plus unique build number) instead of the
CLI version.
* upgrade-juju no longer accepts --bump-version; as described above,
versions are now just bumped when they need to be.
* upgrade-juju now communicates problems rather more helpfully I think.
The main implementation difference is that the detailed upgrade selection
logic is now centered on a separate type (which is somewhat badly named --
upgradeVersions). The command object's fields are now left unchanged from
their values at the end of Init, and Run-specific state is now held within
that method's scope.
One of the details of the implementation difference is that this is the
second place to use the tools.List style access and manipulation, exposed
via the new environs.FindAvailableTools func; branches to use it at
provisioning time and elsewhere should follow quickly.
The other drive-by changes are as follows:
* version.Zero is slightly nicer than version.Number{}. Wish I could make
it const though :/.
* tools.List has a new URLs method that returns its content as a map.
* tools.Newest now also returns the version number shared by the tools
in the original result.
* tests that got tweaked were frequently also reformatted for indentation
and vertical density.
* blank agent-version entries are no longer replaced with a default at
config.New() time: bootstrap is, however, expected to fill in an
agent-version field before the config makes it into state. This
shouldn't really be in this branch, but it got tangled through it;
I'd really like to keep it in because it unblocks a couple of separate
things I need.
* followup: check for missing agent-version at bootstrap time; add
checks to SetEnvironConfig to ensure it's never empty.
https://code.launchpad.net/~fwereade/juju-core/upgrade-select-tools/+merge/158596
Requires: https://code.launchpad.net/~fwereade/juju-core/environs-tools-storage/+merge/157770
(do not edit description out of merge proposal)
Patch Set 1 #Patch Set 2 : upgrade-juju: improvements #
Total comments: 1
Patch Set 3 : upgrade-juju: improvements #
Total comments: 101
Patch Set 4 : upgrade-juju: improvements #
Total comments: 21
Patch Set 5 : upgrade-juju: improvements #
Total comments: 2
Patch Set 6 : upgrade-juju: improvements #
MessagesTotal messages: 12
|