do-release-upgrade should allow other tools to block or warn before upgrades

[James Troup]

do-release-upgrade should allow other tools to block or warn before it proceeds.

A few use cases for this:

 1) Juju managed machines - Juju requires the user to run
    'upgrade-series X prepare' before the upgrade starts. This allows
    charms running on the machine to prepare for the upcoming Ubuntu upgrade.

 2) Paranoid/careful sysadmins (c.f. the 'molly-guard' package)

[Paul Goins (vultaire)]

This would be immensely helpful, especially for case 1 above, which is important to me as a cloud reliability engineer.

When I'm managing a cloud with Juju, and need to do a series upgrade, Juju requires that certain hooks are run prior to performing the do-release-upgrade. If these hooks are not fired, the effects can be fairly serious.

A key example is the use of Python virtualenvs in many charms, especially "reactive" Juju charms. These virtualenvs link into the system Python, and special care must be taken at upgrade time for the virtualenvs to be recreated against the new Ubuntu release's Python, else the virtualenv will become unusable after the upgrade is completed. That's part of the reason for Juju's "upgrade-series" commands.

However, it is very easy for an engineer (read: me) to accidentally miss a step, perform the do-release-upgrade, and realize after the fact that my action resulted in breaking management of the Juju-managed applications deployed on the target machine. And this is actually worse than just that, as often you can't even cleanly remove the affected applications because of the broken virtualenvs. The solution is often to completely redeploy the affected machine by force, which may also has impact on related machines which couldn't communicate with the forcefully redeployed unit during teardown.

The above may not be clear to those who aren't deeply familiar with Juju, but put more simply: not being able to enforce running of Juju's actions prior to upgrade is a risk to Juju-deployed clouds.

If we could have a way for Juju to install a hook, or even simply a "do not run" breadcrumb, so that do-release-upgrade could be blocked until Juju has had a chance to run its pre-release hooks, that would allow Juju to have much more robust series upgrades of Juju managed machines.

[Paul Goins (vultaire)]

It seems that this can kind of be done already. Setting "Prompt=never" in /etc/update-manager/release-upgrades effectively disables the script from performing upgrades. The Juju team has implemented this for controllers to prevent accidentally upgrading them.

Since d-r-u explicitly points out that /etc/update-manager/release-upgrades blocks upgrades in this case, and since comments could be added by Juju or other tools to indicate why upgrades were disabled, I think this bug can be closed as invalid, at least in my opinion.