Skip to content
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

Add support for Pebble change-update notice #17118

Merged
merged 1 commit into from Apr 8, 2024
Merged

Conversation

benhoyt
Copy link
Member

@benhoyt benhoyt commented Mar 28, 2024

This wires up the change-update notice type in the right places, with the effect that we'll now respond to Pebble change-update notices by sending a pebble-change-updated event to the charm.

For reference, Pebble Notices support (for the "custom" notice type) was originally introduced in PR #16428.

Checklist

  • Code style: imports ordered, good names, simple structure, etc
  • Comments saying why design decisions were made
  • Go unit tests, with comments saying what you're testing
  • Integration tests, with comments saying what you're testing
  • doc.go added or updated in changed packages

QA steps

Manual QA steps below (similar to the integration test):

# Pack and deploy the test charm
$ juju add-model t
$ cd testcharms/charms/pebble-notices
$ charmcraft pack
$ juju deploy ./juju-qa-pebble-notices_ubuntu-22.04-amd64.charm --resource redis-image=redis
$ juju status  # unit status should settle to "active" after pebble-ready

# Perform an exec (or any operation that records a change)
$ juju ssh --container redis juju-qa-pebble-notices/0 /charm/bin/pebble exec -- echo foo
$ juju status  # will now say status "maintenance" with message "notice type=change-update kind=exec status=Done"

# List notices:
$ juju ssh --container redis juju-qa-pebble-notices/0 /charm/bin/pebble notices
ID   User    Type           Key  First               Repeated            Occurrences
1    public  change-update  1    today at 02:15 UTC  today at 02:15 UTC  3

# Get notice details for the above notice ID
$ juju ssh --container redis juju-qa-pebble-notices/0 /charm/bin/pebble notice 1
id: "1"
user-id: null
type: change-update
key: "1"
first-occurred: 2024-04-04T02:15:46.249636939Z
last-occurred: 2024-04-04T02:15:46.297160558Z
last-repeated: 2024-04-04T02:15:46.297160558Z
occurrences: 3
last-data:
    kind: exec
expire-after: 168h0m0s

# Get tasks for corresponding change (the notice key "1" above)
$ juju ssh --container redis juju-qa-pebble-notices/0 /charm/bin/pebble tasks 1
Status  Spawn               Ready               Summary
Done    today at 02:15 UTC  today at 02:15 UTC  Execute command "echo"

Documentation changes

Ben to add Juju SDK documentation for this (CHARMTECH-35).

Links

Original spec: JU048.

@hpidcock hpidcock added the 3.5 label Apr 1, 2024
benhoyt added a commit to benhoyt/juju that referenced this pull request Apr 3, 2024
This bumps up the Pebble version to 1.10, which includes the
change-update work (this was going to be done in
juju#17118 anyway) and the security fixes
to the API
(canonical/pebble@a5f6f06).
jujubot added a commit that referenced this pull request Apr 3, 2024
#17140

This bumps up the Pebble version to 1.10, which includes the change-update work (this was going to be done in #17118 anyway) and the security fixes to the API, including the fix for CVE-2024-3250 (canonical/pebble@a5f6f06).

Full Pebble diff: canonical/pebble@v1.9.1...v1.10.2
This is basically just adding the notice type in the right places,
with the effect that we'll now respond to Pebble change-update notices
by sending a pebble-change-updated event to the charm.

This PR also updates "sidecar" integration tests and the pebble-notices
test charm with a change-update notice test.

For reference, Pebble Notices support (for the "custom" notice type)
was originally introduced in PR juju#16428.
@benhoyt benhoyt requested a review from hpidcock April 5, 2024 00:18
Copy link
Member

@hpidcock hpidcock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@benhoyt
Copy link
Member Author

benhoyt commented Apr 8, 2024

/merge

@jujubot jujubot merged commit 42f6a4b into juju:3.5 Apr 8, 2024
32 of 35 checks passed
@benhoyt benhoyt deleted the pebble-v1.10.0 branch April 9, 2024 00:11
benhoyt added a commit to canonical/operator that referenced this pull request Apr 9, 2024
…1170)

This adds support for the new `pebble-change-updated` event (Juju PR
juju/juju#17118), adding a new
`PebbleChangeUpdatedEvent` type and
`{container_name}_pebble_change_updated` event you can observe.

The event has a `get_change()` method to easily fetch the associated
`pebble.Change` object.

It also adds `Harness.pebble_notify` support for the
`pebble.NoticeType.CHANGE_UPDATE` notice type. To use that, you say:

```python
notice_id = harness.pebble_notify('<container>', '<change-id>', type=pebble.NoticeType.CHANGE_UPDATE)
```
@jack-w-shaw jack-w-shaw mentioned this pull request Apr 10, 2024
jujubot added a commit that referenced this pull request Apr 11, 2024
#17182

Merges:
- #17105
- #17117
- #17139
- #17152
- #17158
- #17118
- #17167
- #17175

Conflicts:
- internal/provider/vsphere/image_metadata.go
- internal/provider/vsphere/vm_template.go

Conflicts resulted from the usual context change. Resolved trivially
jujubot added a commit that referenced this pull request Apr 12, 2024
#17191

This reverts PR #17118 ([4afda98](4afda98)), as the interaction between `pebble exec` and hooks turned out to be a big problem.

For example, [prometheus-k8s calls `_update_cert`](https://github.com/canonical/prometheus-k8s-operator/blob/6eea5cc49bce622c089c54a7be0f891e67966c5c/src/charm.py#L169) in the charm's `__init__` (at the start of every hook) which runs `container.exec(["update-ca-certificates"], ...)`. But `pebble exec` records a change for the execution, which records 3 notices, one for every change-update (Hold, Doing, Done). This creates an impossible 3^n fanout of Juju hooks, bogging the system down and preventing other hooks from running.

For now, revert the support for the `change-update` notice and `change-updated` event.

Longer term (probably in 3.6), we clearly need some more design work to handle this kind of thing better. Some braindump thoughts:

* Should Juju exclude change-update notices with kind==exec?
* Or should charmers need to opt in to change-update notice and specify the `kind`s they want? (`exec` will almost never be interesting).
* Perhaps Pebble shouldn't record a change for `exec` at all.
* Juju should probably batch up change-update notices into a single hook? (Or maybe even all notices, but with `custom-notice` that ship has already sailed.)
* Separately, is it a good idea for a charm to call exec in charm `__init__`?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
4 participants