JUJU_HOOK_NAME does not get set

[Robie Basak]

Using 1.24.6, JUJU_HOOK_NAME (documented in https://jujucharms.com/docs/stable/reference-environment-variables) is not getting set, at least for the install, config-changed and upgrade-charm hooks. I verified this by dumping the environment to stderr and exiting non-zero in the install hook and looked at /var/log/juju for that output.

However, it does seem to get set when debug-hooks is used, so this is doubly dangerous - hooks are not being debugged in the same environment that they are run normally.

I am using the manual provider.

[Curtis Hovey (sinzui)]

This appears to be a documentation failure. JUJU_HOOK_NAME is only set when running debug-hooks where the execution context is unclear. scripts can learn the hooks name using $0, ${BASH_SOURCE[0]}, or sys.argv[0] for example.

[Robie Basak (racb)]

Yeah I used $0 as a workaround.

I think this should be fixed in behaviour though, not in documentation, since it unnecessarily makes heisenbugs possible. The debug-hooks environment should be identical to the production environment as much as possible (obviously connection to a terminal is a difference, but apart from that the goal should be to converge differences, not create them).

[Cory Johns (johnsca)]

I think that having JUJU_HOOK_NAME always set would be much better. $0 doesn't work if you call out to a helper, so any charm using the command-line interface to charm-helpers will be broken, and it also breaks the bash layer functionality of charms.reactive.

Can we consider changing the code to match the documentation instead?

[Robie Basak (racb)]

> $0 doesn't work if you call out to a helper

My workaround for now is to manually set JUJU_HOOK_NAME in the first wrapper using $(basename "$0") if it isn't already set. But this does require control over the first wrapper, which can be awkward if a charm isn't written by a single author.

[Katherine Cox-Buday (cox-katherine-e)]

Spoke with fwereade. There's no reason we shouldn't be able to set this 100% of the time. I'll pick this up and update the documentation when I get a chance.

[Stuart Bishop (stub)]

I think this has been fixed? As of which version?

[Cheryl Jennings (cherylj)]

A quick grep of the code leads me to believe that this hasn't been fixed yet.

[Anastasia (anastasia-macmood)]

Thank you, Robie Basak \o/
"juju" is current Juju 2 bug tracking project :D

[Robie Basak (racb)]

I just filed this bug: https://bugs.launchpad.net/ubuntu/+bug/1634201; I
Cc'd the bug so as to try and not fragment any discussion.

During development, we have packages in -proposed that fail to migrate,
as expected, for good reason.

At release time, these packages are still present. For example, Yakkety
released with libhcrypto4-heimdal:amd64 1.7~git20160703+dfsg-1 in
proposed, which is not in the release pocket because it is broken (see
bug 1617963).

I think we should be encouraging users to volunteer to risk testing
proposed in stable releases. This helps with SRU verification.

However, our current release process breaks these users when they
upgrade to a new release (which, given that they are testing the cutting
edge, they are likely to do early, before the proposed pocket has been
cleaned out).

This means that users, instead of being encouraged, are being
discouraged from testing the SRU proposed pocket since we are breaking
them with known bugs but delaying removal of those breakages.

Bug 1633653 is an example: a user with xenial-proposed enabled upgraded
to Yakkety one day after release, and this broke.

How can we adjust our release process to stop this happening?