-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add support for Pebble check events #151
feat: add support for Pebble check events #151
Conversation
Also update the support for Pebble notices to be aligned with the 7.x approach.
status: pebble.CheckStatus = pebble.CheckStatus.UP | ||
"""Status of the check. | ||
|
||
CheckStatus.UP means the check is healthy (the number of failures is less | ||
than the threshold), CheckStatus.DOWN means the check is unhealthy | ||
(the number of failures has reached the threshold). | ||
""" | ||
|
||
failures: int = 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if the defaults should be reversed here, to CheckStatus.DOWN and e.g. failures=3. The normal situation should be that the check is passing, but if it's passing then I doubt people would be creating the event and putting it into the container (if that was done automatically with a tool, then it would not require the defaults).
I think observing and therefore testing pebble-check-failed is probably more likely than pebble-check-recovered, so that would lean me towards making a failing check the one that requires the least work. Or maybe charms will always observe both, in a kind of do/undo pattern?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what you have (UP, 0) is better, as it matches the Pebble "defaults". So it seems more explicit and less surprising to me than having it (DOWN, 3) as a default, even if it's a bit more work for tests that use it.
#17655 This creates new `<container-name>-pebble-check-failed` and `<container-name>-pebble-check-failed` hooks, which are triggered by Pebble change-update notices of particular kinds & statuses, with the effect that we'll now respond to Pebble checks reaching the failure threshold, or passing after having reached the threshold, by sending a pebble-check-failed or pebble-check-recovered event to the charm. ## QA steps ### Test the hooks directly: ```shell # Pack and deploy the test charm $ juju add-model t $ cd testcharms/charms/pebble-checks $ charmcraft pack $ juju deploy ./juju-qa-pebble-checks_ubuntu-22.04-amd64.charm --resource ubuntu-image=public.ecr.aws/ubuntu/ubuntu:22.04 # The check is set to succeed if `/trigger/` exists, so make it. $ juju ssh --container ubuntu juju-qa-pebble-checks/0 mkdir /trigger/ $ juju status # unit status should settle to "active" after pebble-ready # Make the check fail $ juju ssh --container ubuntu juju-qa-pebble-checks/0 rmdir /trigger/ $ juju status # will now say status "maintenance" with message "check failed: exec-check" # Make the check pass again $ juju ssh --container ubuntu juju-qa-pebble-checks/0 mkdir /trigger/ $ juju status # will now say status "active" with message "check recovered: exec-check" ``` ### Test the shell test: `./main.sh -p k8s -c minikube sidecar test_pebble_checks` ## Documentation changes prdesc [CHARMTECH-160](https://warthogs.atlassian.net/browse/CHARMTECH-160), [CHARMTECH-161](https://warthogs.atlassian.net/browse/CHARMTECH-161), [CHARMTECH-162](https://warthogs.atlassian.net/browse/CHARMTECH-162) cover updating the juju.is (main and SDK) docs ## Links <!-- Link to all relevant specification, documentation, bug, issue or JIRA card. --> * [OP046](https://docs.google.com/document/d/13ItH8l5ZSmmv9WqZXpqjV8EifZU5e3zxINiNLubnC68/edit) * [juju/charm PR](juju/charm#432) * [ops PR](canonical/operator#1281) * [pebble PR](canonical/pebble#444) * [jhack PR](canonical/jhack#172) * [Scenario PR](canonical/ops-scenario#151) **Jira card:** [CHARMTECH-109](https://warthogs.atlassian.net/browse/CHARMTECH-109) [CHARMTECH-160]: https://warthogs.atlassian.net/browse/CHARMTECH-160?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
The merge broke the linting check because I forgot to reorder them. I'll fix that later. The test pass if you use ops main - I assume we would not merge this until that's become 2.15 anyway, so will trigger the tests before that. |
status: pebble.CheckStatus = pebble.CheckStatus.UP | ||
"""Status of the check. | ||
|
||
CheckStatus.UP means the check is healthy (the number of failures is less | ||
than the threshold), CheckStatus.DOWN means the check is unhealthy | ||
(the number of failures has reached the threshold). | ||
""" | ||
|
||
failures: int = 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what you have (UP, 0) is better, as it matches the Pebble "defaults". So it seems more explicit and less surprising to me than having it (DOWN, 3) as a default, even if it's a bit more work for tests that use it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good -- thanks. Just one minor comment about the CheckInfo
argument name.
* Add support for Pebble checks. Also update the support for Pebble notices to be aligned with the 7.x approach.
Adds support for the {container-name}-pebble-check-failed and {container-name}-pebble-check-recovered events that will be available in Juju 3.6.
Example usage:
Also updates the support for Pebble custom notice events to align with the 7.x approach (event from ctx.on, notices are a frozenset).
Updated usage: