Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle series upgrade for machine upgraded out-of-band #11764

Merged
merged 12 commits into from Jun 26, 2020

Conversation

manadart
Copy link
Member

Description of change

This patch handles the case where do-release-upgrade is run outside of the intended upgrade-series workflow.

In the example of upgrading a machine from Xenial to Bionic, with Juju still thinking the machine is running Xenial, we see:

  • The series upgrade is able to be commenced for what appears to be a valid upgrade.
  • When running, the worker detects Bionic on-machine for the "from" series.
  • An error results when attempting to copy agent binaries not present for that series - they are in the Xenial location.

This patch still uses the locally determined series for detecting the init system, but for copying binaries we use the current machine series according to Juju's data.

QA steps

  • Bootstrap to LXD.
  • Add 2 machines via juju add-machine --series xenial.
  • juju ssh 0 and run do-release-upgrade, confirming prompts as required.
  • For each machine:
    • juju upgrade-series [0|1] prepare bionic -y. This should complete without error.
  • Finish upgrade for the already upgraded host: juju upgrade-series complete 0.
  • juju ssh 1 and run do-release-upgrade, confirming prompts as required.
  • juju upgrade-series complete 1.
  • Check that the machines have been upgraded to Bionic via Juju status.

Documentation changes

None.

Bug reference

https://bugs.launchpad.net/juju/+bug/1870195

Includes some variable renaming and error annotation clarification.
and facade factory.

This behaviour was not required due much older changes and is a logical
simplification.
CurrentSeries method for accessing what Juju thinks the machine series
is at present.
the current OS series is.

This is populated by supplying the value from the new CurrentSeries API
method.
thinks the current series is rather than what the machine reports.
@manadart
Copy link
Member Author

Copy link
Contributor

@achilleasa achilleasa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few comments; doing QA ATM

apiserver/facades/agent/upgradeseries/upgradeseries.go Outdated Show resolved Hide resolved
service/agentconf.go Show resolved Hide resolved
@manadart manadart added the 2.8 label Jun 26, 2020
Copy link
Contributor

@achilleasa achilleasa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

QA worked as expected.

@manadart
Copy link
Member Author

$$merge$$

@jujubot jujubot merged commit ea1db6d into juju:2.8 Jun 26, 2020
@manadart manadart mentioned this pull request Jun 26, 2020
jujubot added a commit that referenced this pull request Jun 26, 2020
#11767

Zero-conflict merge from 2.8 to bring forward:
- #11764 from manadart/2.8-series-upgrade-already-done
- #11763 from achilleasa/2.8-display-channel-when-upgrading-charm
- #11762 from SimonRichardson/error-messages
@manadart manadart deleted the 2.8-series-upgrade-already-done branch July 22, 2022 15:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants