Pulse #8 highlights: We’ve got some fantastic new features and improvements for you: added support for user secrets in Harness, improved the ops usage in the Juju Kubernetes charm tutorial, improved configuration, improved ops-scenario API, finished initial implementation in Pebble of health checks as changes and tasks, and more!
The ops library
- Good news! We’ve added support for user secrets in
Harness
. Every secret has an owner – the entity creating, updating, sharing, or removing it. Starting with Juju 3.3, the secret owner can be a user with model admin access, in which case, the secret is known as a “user secret”. To add a user secret, you can runjuju add-secret
, and now in your test, you can simulate this behaviour by callingHarness.add_user_secret
. - Configuration just got better! We’ve fixed the types related to the model, and we’re making it easier to use secrets in the config. Instead of explicitly calling
Model.get_secret
after reading the secret ID from the config, we’re planning on providing a direct way to access the secret object. Check out the draft PR here! - We’re also working on converting tests in the ops framework from
unittest
topytest
style. It’s still a work in progress, but we’re aiming to get it done before the next cycle. - Unfortunately, we had to revert the previously introduced support for
pebble-change-updated
notice due to a fan-out issue with its usage in Juju, which was reverted. We’ll give it another shot in the future, possibly in Juju 3.6.
Charming
- Great news for users of the Juju Kubernetes charm tutorial! We’ve made significant improvements to the ops usage, including better import statements, fixing
isort
version issues, avoiding unnecessarycan_connect
calls, eliminatingSystemExit
raises, and more. - We’re adding Scenario support for Pebble custom notices and CloudSpec.
- Helped review Kratos External IDP charm to make it searchable in Charmhub.
- @tony-meyer has been working hard on removing
python-libjuju
AllWatcher and identifying gaps in Juju API without it. The Juju team will be removing the AllWatcher in Juju 4.0. The Charm Tech will help out with this by releasing a newpython-libjuju
version that works with both 4.0 and 3.6, which does not use the AllWatcher. This will make a significant difference, especially for large models where running an AllWatcher can be expensive but all you want to do is deploy and query the state of a single application. This pulse, we’ve looked into what gaps there are in the Juju API in order to make this happen. - As mentioned earlier, Juju’s support for the new Pebble change-update notice has also been reverted.
Pebble
- Exciting progress has been made on implementing health checks via Changes and Tasks (JU073).
- We’ve addressed minor issues, such as reserving layer labels) starting with the “pebble-” prefix, validating IDs used in URL paths on the client side, and requiring admin access for certain operations.
- We’re also introducing a flag to ensure that pebble make-dirs permission won’t be masked by
umask
. Additionally, we’re planning some code refactoring to improve the API and reduce duplication; see the discussion here. - @benhoyt has been working with @hpidcock on the spec of Pebble API authentication (JU092).