ops 2.21.0, ops-tracing 2.21.0 and ops-scenario 7.21.0 released: ops[tracing] and pebble identities

Charm Tech is delighted to announce the simultaneous release of ops 2.21.0, ops-tracing 2.21.0 and ops-scenario 7.21.0.

What’s Changed

This release adds ops[tracing], the first-party tracing support for your charms, support for reading and setting Pebble identities and a change where a new instance of the charm class is used for each deferred event.

Head over to documentation to learn how to use ops[tracing]!

Potential gotchas

Due to Builds fail for 20.04 (in some common circumstances) · Issue #2259 · canonical/charmcraft · GitHub, your charm may not build against 20.04 base, if you are using requirements.txt or other mechanism that enforces building all dependencies from source. Please wait for charmcraft 3.4 hot fix or migrate to the uv plugin. The issue is not unique to ops, however this release brings in a new dependency that is affected. If yours is a simple charm without complex charm libs, you may be able work around the issue by restricting your dependencies, like ops <= 2.20.0.

Each deferred event is now run in a fresh instance of your charm class. The change should be safe for most charms, however, if your charm defers events and shares data between the deferred event and the current event in the charm class, please test thoroughly. The Ops pre-commit and commit events are also now emitted after each deferred event, so if you use those and defer, please check that it’s safe to have them run more than once per hook.

We have made a patch release: ops 2.21.1, ops-tracing 2.21.1, ops-scenario 7.21.1

This release reverts the “use new charm instance to run deferred events” change from 2.21.0, as that broke some charms that relied on only-once semantics to run custom upgrade code and also deferred events.

1 Like