Missing base hooks: leadership, update-status, storage

[marcoceppi]

New hooks exist since 1.23 of Juju which are not modeled in the base layer:

• leader-elected
• leader-settings-changed
• {storage}-storage-attached
• {storage}-storage-detaching
• update-status

where {storage} is defined under the top level storage key in metadata.yaml

It'd be great to have them there by default

[chuckbutler]

+1 to this

Missing update-status, and upgrade-charm hooks leave me with reactive charms that don't respond properly when decorating with @hook() decorators, as the hook exits 0 - never reaching the proper hook context in the reactive methods.

[johnsca]

I'm a little bit hesitant about including update-status by default, because would trigger any matching handler every time the hook was invoked, every 5 minutes. While this should be fine if the charms are coded well and are properly idempotent and properly gate behavior behind "if changed" clauses, it could still lead to more actions being taken on update-status than might be expected.

In some cases, this could actually be useful behavior, though, since sometimes it can be difficult to get a service to retry a hook that resulted in "blocked" status, but I wonder if it might not be worth gating it behind some sort of layer option?

[marcoceppi]

Would it be possible for charm build to sniff all @hook decorators and add
hooks that are in a whitelist that wouldn't be added by default?

On Mon, Nov 16, 2015 at 3:41 PM Cory Johns notifications@github.com wrote:

I'm a little bit hesitant about including update-status by default,
because would trigger any matching handler every time the hook was invoked,
every 5 minutes. While this should be fine if the charms are coded well and
are properly idempotent and properly gate behavior behind "if changed"
clauses, it could still lead to more actions being taken on update-status
than might be expected.

In some cases, this could actually be useful behavior, though, since
sometimes it can be difficult to get a service to retry a hook that
resulted in "blocked" status, but I wonder if it might not be worth gating
it behind some sort of layer option?

—
Reply to this email directly or view it on GitHub
juju-solutions#4 (comment)
.

[johnsca]

Not really, because of the external / non-python handlers; it's not really possible to introspect them.

I should perhaps clarify that I'm not entirely adverse to including update-status by default, but we would just need to make sure we call it out as a consideration in the docs.

[johnsca]

juju-solutions/reactive-base-layer#12
juju/charm-tools#67
juju-solutions/reactive-base-layer#13

[johnsca]

These are all available now.