charms.openstack ought to only call assess_status() once per charm invocation

Bug #1662238 reported by Alex Kavanagh on 2017-02-06
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Currently, the onus is on the charms author to call assess_status() in a handler when they want to update the status.

However, charms.reactive's approach to calling handlers during a @hook context often means that multiple handlers may get run, which means that assess_status() may often be called multiple times. These are often fairly expensive calls and result in multiple calls to Juju's CLI status_set command.

Thus, this bug is to suggest a way to only make the actual call to status_set() once, and also to defer the assess_status() call to the end of the charm's invocation.

The charmhelpers.core.hookenv.atexit() command provides a mechanism to run a function before the charm exits. However, charms.reactive ALSO uses this to do some clean-up, and charms.openstack would need to do its work (perhaps) just before charms.reactive.

Interestingly, charmhelpers.core.hookenv.atexit() runs the handlers in reverse order, so we can piggyback onto charms.reactive atexit() hooks as (in theory) the charms.openstack module will be imported AFTER charms.reactive.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers