Add collect-status events for multi-status handling #954
Conversation
benhoyt
changed the title
| ] | ||
| calls = fake_script_calls(self) | ||
| self.assertRegex(' '.join(calls.pop(-2)), 'Initializing SQLite local storage: ') | ||
| self.assertRegex(' '.join(calls.pop(-3)), 'Initializing SQLite local storage: ') |
There was a problem hiding this comment.
I do not like how we have these brittle indexes in the tests, but I've left that as is for future cleanup work!
| @@ -620,6 +624,7 @@ def test_collect_metrics(self): | |||
| VERSION_LOGLINE, | |||
| ['juju-log', '--log-level', 'DEBUG', '--', 'Emitting Juju event collect_metrics.'], | |||
| ['add-metric', '--labels', 'bar=4.2', 'foo=42'], | |||
| ['is-leader', '--format=json'], | |||
There was a problem hiding this comment.
The testing of _evaluate_status is done in test_charm.py; all this has to do is test whether it's called.
(in the cases where people aren't using static type checking)
This comment was marked as outdated.
This comment was marked as outdated.
There was a problem hiding this comment.
Overall it does what we were intending, which is to provide a way to do callbacks to set the status of the application, and be able to handle multiple pieces that want to have a say on the status, without having one of them resolving causing the others to get confused.
Log these at stacklevel=2 so we log the caller, not add_status
|
I decided to do the debug logging a different way. Log every call to |
Why would we not want to log active? |
Because I expect that a lot of the time there'll be several
I guess you're probably thinking ahead to parsing these in jhack, but I'd really rather not commit to a particular format of log debug message as a kind of API. I don't mind tweaking what we have in future to make jhack's life easier, but I think I'm going to merge what I have for now. |
Per John M's suggestion on Mattermost: https://chat.charmhub.io/charmhub/pl/59gsuisc6jdi9mxnhej7pethjr See also: canonical/operator#954 (comment)
#15962 Per @jameinel's [suggestion on Mattermost](https://chat.charmhub.io/charmhub/pl/59gsuisc6jdi9mxnhej7pethjr), we should prioritize Maintenance (which means "we're busy") above Waiting ("someone else is busy"). > I highly doubt that anyone has code that uses the fact that Maintenance is lower priority than Waiting to make a decision out in the wild. See also: canonical/operator#954 (comment)
This implements the
collect_app_statusandcollect_unit_statusevents that can be used by charms to allow the framework to automatically collect status (from multiple components of the charm) and set status at the end of every hook.API reference under
CollectStatusEvent, though I'll also add usage examples to the new "charm status" SDK doc that Dora is creating.Spec and examples described in OP037.
The implementation is very straight-forward:
model.Applicationandmodel.Uniteach have a list of_collected_statuses, andCollectStatusEvent.add_statusadds to the correct one of those. Then after every hook inops/main.pywe call_evaluate_status, which triggers each event and sets the app or unit status to the highest-priority status collected (if any statuses were collected). Note thatcollect_app_statusis only done on the leader unit.To test when using
ops.testing.Harness, useHarness.evaluate_status.This has full unit tests, including in
test_main.py, but I've also confirms this works on a real production deploying on Juju.