canonical
Upgrading charm does not recreate the hook symlinks
I have re-written an existing charm from an older framework to operator. On running upgrade-charm, the charm code is put in place correctly, but the symlinks one expects in ./hooks/ are not created (only the install hook is there).
Deploying to a new unit is fine, this only affects when we're upgrading charm code on existing units from non-operator to operator.
Is there something we should be doing to avoid this situation?
This is unexpected as upgrade-charm is one of the triggers we use for creating the symlinks. Provided you've symlinked it for the charm to actually trigger from it. (you want install and upgrade-charm and if you want to support juju <2.7.6 start so that the framework is given the opportunity to do the rest)
On Wed, May 6, 2020, 05:21 xavpaice [email protected] wrote:
I have re-written an existing charm from an older framework to operator. On running upgrade-charm, the charm code is put in place correctly, but the symlinks one expects in ./hooks/ are not created (only the install hook is there).
Deploying to a new unit is fine, this only affects when we're upgrading charm code on existing units from non-operator to operator.
Is there something we should be doing to avoid this situation?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/canonical/operator/issues/256, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABRQ7OXSZ7MT5CP3KP74I3RQC3R7ANCNFSM4M2BJZXQ .
Adding the symlink to upgrade-charm did indeed fix this - this probably is a charm template/doc issue then?
Yeah. We recommend install, start, upgrade-charm as being the default symlinks. (start is optional, but it means compatibility with older Juju.)
Ultimately we'll want to switch to dispatch which handles all events, and leaves you with just 1 symlink. The patch for this just landed in the operator framework, and it is only supported by Juju 2.8.
On Wed, May 6, 2020 at 9:22 AM xavpaice [email protected] wrote:
Adding the symlink to upgrade-charm did indeed fix this - this probably is a charm template/doc issue then?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/canonical/operator/issues/256#issuecomment-624447539, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABRQ7NKRCMQN2PB4PW4F2LRQDXYFANCNFSM4M2BJZXQ .
I've got a semi-related issue with regard to this and issue #362. On a juju 2.6.5 model, I'm having trouble with the dispatch fix from #362 after upgrading charm that's patched with the latest dispatch symlink fix.
We previously installed a version of the charm pre-patch for #362 which created ../src/charm.py symlinks for config-changed. However, upon upgrade-charm (cs:~llama-charmers-next/cloudstats-1), The charm left the old symlinks in place rather than clearing the hooks directory (per the charm's archive in charmstore) and letting dispatch re-create the symlinks during upgrade-charm.
Resultant are the following symlinks in my hooks directory. The relations are new to the charm, the config-changed is not.
lrwxrwxrwx 1 root root 15 Jun 22 02:45 collect-metrics -> ../src/charm.py
lrwxrwxrwx 1 root root 15 Jun 22 02:45 config-changed -> ../src/charm.py
lrwxrwxrwx 1 root root 13 Oct 23 14:13 grafana-dashboard-relation-broken -> upgrade-charm
lrwxrwxrwx 1 root root 13 Oct 23 14:13 grafana-dashboard-relation-changed -> upgrade-charm
lrwxrwxrwx 1 root root 13 Oct 23 14:13 grafana-dashboard-relation-created -> upgrade-charm
lrwxrwxrwx 1 root root 13 Oct 23 14:13 grafana-dashboard-relation-departed -> upgrade-charm
lrwxrwxrwx 1 root root 13 Oct 23 14:13 grafana-dashboard-relation-joined -> upgrade-charm
It seems that this may be a juju agent upgrade-charm issue and not something operator can cleanly solve itself.
I would have expected during upgrade-charm that the statedb would be retained, but everything else in the /var/lib/juju/agents/unit-cloudstats-0/charm directory would be wiped and re-initialized to the new package's state, but somehow those symlinks created by the old operator framework from June 22nd still exist.
To reproduce, deploy a simple charm with a few symlinks defined in hooks/ that link to ../src/charm.py. Then remove the symlinks in the charm code and upgrade-charm to that new charm...the symlinks appear to stay even though they should be regenerated to point to upgrade-charm per the fix from #362.
