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_secretafter 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 
unittesttopyteststyle. 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-updatednotice 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 
isortversion issues, avoiding unnecessarycan_connectcalls, eliminatingSystemExitraises, 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-libjujuAllWatcher 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-libjujuversion 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).