upgrade path for applications series (ie. trusty to xenial)

[Alvaro Uria]

In Juju2, when an application charm supports multiple series (ie. trusty, xenial) and the application is deployed in trusty series, is there any plan to support upgrades to later series (ie. trusty LXD upgrade to xenial)?

I understand there are limitations:
* not any series jump would be supported
* do-release-upgrade needs to be run on container, kvm or baremetal
* in juju-db, db.services needs to be updated (series key), but only after all units of such application are upgraded.
* such container/kvm/baremetal can have other applications running (ie. subordinates, smooshed apps), which should also be upgraded (if supported, in juju-db's db.services)
* new units of the upgraded applications would be deployed under the new series

OTOH, OpenStack charms support "openstack-origin" parameter which could point to trusty updates.

[Heather Lanigan (hmlanigan)]

There is a longer term project underway to accomplish this.

I am currently working on a stepping stone piece, where if you have manually updated the series of existing units, you'll be able to let juju know that new units should use this new series. You
would be able to change the series to any supported by the charm, so a 'revert' action would be
possible.

Current thinking is along the lines of:
juju upgrade-charm <application> --series <new series>

[Heather Lanigan (hmlanigan)]

After much discussion, there is a change of plan for the juju command name to:

juju update-series <application> <series> [--force]
New units of the application will use the new series

juju update-series <machine> <series [--force]
The current machines will be marked in the db has having the new series. The charms' config changed hook will be triggered.

[Heather Lanigan (hmlanigan)]

PR in 2.2 for juju update-series <application>...
https://github.com/juju/juju/pull/7677

Work on juju update-series <machine> has started.

[Heather Lanigan (hmlanigan)]

PR 7677 has been merged into the develop branch for 2.3. Work will commence on the machine update piece now.

Information on how to manually update the juju database for juju 2.0 to 2.2.x will be provided.

[Mario Splivalo (mariosplivalo)]

Am I correct in assuming that the upgrade itself will be made by charms itself?

Would it make sense to add 'updgrade-series' hook, that will take care of series upgrades?

I'm asking because I can envision multiple scenarios (mainly with databases) where series upgrade can't be just done with 'do-release-upgrade' but will require coordination from the deployed units (thinking about various databases that will need to be upgraded one-by-one, esp if they are in HA setup).

[Heather Lanigan (hmlanigan)]

juju update-series <machine> pr into develop:
https://github.com/juju/juju/pull/7776

[Heather Lanigan (hmlanigan)]

@mariosplivalo,

For existing units, the current plan is for a qualified person to do the dist upgrade. We will be providing documentation and scripts to help migrate the juju pieces from
upstart to system for a trusty to xenial upgrade. As well as anything else which needs manual attention.

When complete, the functionality will include the config-changed hook being run as part of
'juju update-series <machine>'. The charms will evolve to look for underlying machine series in config-changed.

There is also the option, provided there are available resources, to add and remove units after running 'juju update-series <application>' to avoid doing the dist upgrade on existing units.

[Heather Lanigan (hmlanigan)]

Doc PR on how update series for an application pre-juju2.3 : https://github.com/juju/docs/pull/2019

[Heather Lanigan (hmlanigan)]

PR to trigger config-changed hook when a unit's series changes:
https://github.com/juju/juju/pull/7794

[Heather Lanigan (hmlanigan)]

Doc PR on how update series for an machine pre-juju2.3 : https://github.com/juju/docs/pull/2045

All juju develop PRs have been merged.