Need upgrade path from non-reactive charms to reactive

[johnsca]

Doing in-place upgrades from a non-reactive charm to a reactive implementation is difficult primarily due to needing to get the reactive states set up to reflect the environment as is currently deployed. Part of this can be done in an @hook('upgrade-charm') handler, but we at a minimum need some sort of helper to get the interface layers to the correct state.

[johnsca]

One option might be to "fake" the -relation-joined and -relation-changed hooks for every relation to allow the interface layers to get their states in place. There are likely idempotency issues in some interface layers. Also, we might have to run only the hook phase for this, though, because the charm might try to react to the join in a non-idempotent way.

[mbruzek]

An issue I have experienced is charms written in python version 2 not running in xenial 16.04 because only python version 3 (python3) is installed by default on xenial cloud images.

This is technically not a non-reactive to reactive issue, but we may need to ensure that the python code is up to version 3 standards as all reactive charms are generated with python3 shebangs.

[johnsca]

@mbruzek You could also manually install python2 in a sort of pre-install hook, as a quick-fix. Though there are some difficulties in managing this now because there is no longer a guarantee that install will be the first hook run (leadership and storage hooks could both potentially run before install, and there might be others).

[arosales]

One thought for the Precise chamrs. Perhaps we deprecate precise ahead of its EOL, and state that reactive Precise charms are not supported. An even bigger statement we could make is that Juju Curated Charms do not support Precise.