For several months we’ve wanted to encourage greater adoption of new features that Charm Tech adds (to Ops, charmlibs, Jubilant, …). We talked to people about this, and we understand that part of the hesitance is that when you’re focused on polishing an LTS charm, you’re not wanting to adopt new features, no matter how great they are. However, we also heard that you’d like to have more support in picking features up when you’re working on a new charm or new channel.
The other change in the last year is, of course, the rise of agent-written code, at quality levels and prices that it’s reasonable to expect that these sorts of upgrades can mostly be written for you.
To demonstrate what’s possible, we picked a few features that we’d like to see more adoption of, and charms we felt would be good candidates. For each upgrade, the code change and passing unit tests took a few minutes, charmcraft pack succeeded, and the charm’s own integration tests passed in CI before and after the changes.
Demo upgrades
Moving to the charmlibs-tls-certificates package in the forgejo-k8s-operator charm:
- Roughly two minutes
- +8, -2532 across five files (predominately the de-vendoring, of course)
- PR in a fork
Using typed config in wireguard-gateway-operator:
- Roughly three minutes
- +77, -70 in src/charm.py, plus 171 lines of new tests
- PR in a fork
Using Juju secrets in grafana-cloud-integrator:
- Roughly three minutes
- +92, -10 across the two charm libraries, plus new unit and integration tests
- PR in a fork
Using ops[tracing] on ubuntu-manpages-operator:
- Roughly nine minutes
- +145, -35
- PR in a fork
And more in the works!
Process
For each feature, we picked a charm from charmtally’s gap list for that feature, and checked that its integration suite can run on a fork in GitHub actions (it was easier for us if a self-hosted runner and workflow secrets were not needed; you’d be able to handle that, of course). We ran the unmodified CI to get a “before” run.
We then gave an agent the feature’s documentation and a short migration brief. We found that just the documentation wasn’t enough (we’re working on improving that), because often the agent needed things that were harder to find in the docs: changes for a charm that’s already deployed, traps in an existing test suite, working around a couple of doc bugs (fixed now!).
The agent worked on a branch from upstream main and then we did the agent-y thing of looping until:
- unit tests were consistently passing
charmcraft packsucceeded- the charm’s integration suite passed on the fork
The times are from the start of the work until the unit tests passed. Packing and integration tests took 10-25 minutes for these charms, but we’re all accustomed to going off and doing other things while that’s happening.
Tell us what you need
Would you find a series of posts on specific upgrades useful? If so, what features would you like us to focus on? We can start with any of our demo upgrades, but also do whatever else there’s demand for.