-
Notifications
You must be signed in to change notification settings - Fork 57
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: include check name in notice data for perform-check and recover-check #444
Conversation
…er-check change-updated notices. Code heavily based on a suggestion from @benhoyt.
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.
Nice work! Some small changes requested for comments and error message.
I've also tested locally and see the check-name nicely in the state file:
{
"id": "1",
"user-id": null,
"type": "change-update",
"key": "1",
"first-occurred": "2024-07-05T03:50:52.556541656Z",
"last-occurred": "2024-07-05T03:51:46.633442924Z",
"last-repeated": "2024-07-05T03:51:46.633442924Z",
"occurrences": 4,
"last-data": {
"check-name": "chk1",
"kind": "perform-check"
},
"expire-after": "168h0m0s"
}
Co-authored-by: Ben Hoyt <[email protected]>
Ah, yes, thanks. I should have mentioned that I checked that and also locally tested that wait notices has it in the last data as well. |
#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
…1281) Two new event types are supported (actually getting these events requires Juju 3.6b2 or higher): * `PebbleChangeFailedEvent` - emitted when a Pebble check in a container hits the failure threshold * `PebbleChangeRecoveredEvent` - emitted when a Pebble check in a container passes after previously hitting the failure threshold Each event type has a single new attribute (in addition to those inherited from `WorkloadEvent`): * `info` - this is a shortcut to Pebble's `get_check` method (not otherwise accessible from the charm), but will only query Pebble if more than the `name` is requested, and will cache the result on the event instance. Two new enums are added to Pebble, to make it easier to work with these events, particularly with Harness: * `ChangeStatus` - the possible values for `ops.pebble.Change.status` (note that this is the full list, but we only expect charms to see Doing, Done, and Error for now). * `ChangeKind` - the possible values for `ops.pebble.Change.kind` (again, this is the current full list, but we only expect charms to see perform-check and recover-check at the moment). `Harness.pebble_notify` is extended to support emitting the two new events. This requires implementation knowledge (that the check events are triggered by a Pebble notice of type change-updated), but provides minimal support for testing with Harness, and will be supplemented by user-friendly testing in Scenario. The testing Pebble backend gains an implementation for `get_change` and `get_checks`. These are not used directly here, but will be used in Scenario, and it makes more sense to have the implementation in ops. This is the ops portion of [OP046](https://docs.google.com/document/d/13ItH8l5ZSmmv9WqZXpqjV8EifZU5e3zxINiNLubnC68/edit). It requires a [corresponding change to Pebble](canonical/pebble#444) and [change to Juju](juju/juju#17655).
For notices of kind
change-updated
, the notice data will include thekind
field that is standard for these notices, but also whenkind
isperform-check
orrecover-check
, it will also includecheck-name
, set to the name of the check that is being performed or recovered.This is the Pebble portion of OP046. It is used by Juju (PR) and ops (PR).