40 people answered the 26.10 charming survey. Thanks to everyone who took the time; it really helps us out! Here’s a summary of how it’s influencing our 27.04 work, including the draft roadmap (please provide feedback, if you’re inside Canonical!).
—
Remember that you’re welcome to open issues on any of the Charm Tech projects any time in the cycle. We set aside around 3 hours per person per week to work on these, and got through around 100 during 26.10, so there’s definitely a chance that we’d do your request. The more information you can provide about why it’s worth doing, the more likely that it’ll end up in that bucket of work (or, if it’s large, in a future roadmap).
—
We had some smaller requests for Ops:
- a way to know what kind of cloud the charm is running on, without reading environment variables: you should be able to get this from
get_cloud_spec()- please reach out if that isn’t sufficient. - exposing the owner of a Juju secret: unless ‘you’ are the owner, this information isn’t available - please ask the Juju team for a secret-info-get (or similar) for non-owners, and if that becomes available, we’ll definitely model it in Ops.
- a way to tell that an application (rather than a unit) is going away: we’re pretty sure that Juju would need to provide this one too, please ask the Juju team for a new event or something else to solve this.
- an API for copying a directory from the charm container into the workload container:
push()should provide most of what’s needed here - if you’re missing something, please reach out to us.
Charms that need a proxy on Kubernetes were raised as a gap with real cost, since there is no equivalent of the machine-charm approach and each charm ends up writing its own tunnelling and environment-variable boilerplate. We’ll schedule a discussion at the upcoming sprint for this one, as we’re not clear enough on what should be done to put it into the roadmap.
On Ops documentation, we opened a couple of small tickets:
- what Juju does on SIGTERM in Kubernetes
- how action failures interact with event failures, secrets, and defer
Several people find the reference hard to navigate as a single large page, and missed the sidebar (which only appears with a wide screen). We’re hoping that the new documentation theme will solve this.
On unit testing, the requests were:
- a way to carry state between tests so a sequence of events can be tested as one workflow: you can already re-use the
Stateobject; reach out if that isn’t providing what you need. - default mocks for package installation and service management, so machine-charm tests don’t have to hand-roll them: this is on our 27.04 draft roadmap - only snaps to start with, but once we’ve done that, we’ll most likely do apt as well.
- mocking of file metadata: we hoped to have this on the 27.04 roadmap, but ran out of space. It’s on the list of things we’ll try to get to if we find some extra time.
- support for newer type checkers, which currently don’t work well against ops[testing]: we’ve done some research here, and will try to address this soon.
A couple of requests for Jubilant:
- quieter default logging: done in 26.10
- for support for older Juju versions: this already exists: jubilant-backports
Concierge requests:
- additive presets that can be combined: we’re going to look into this as part of the preset work in 27.04; we’re not sure yet whether we want to do this or not.
- presets that cover storage and offline setup: on the 27.04 draft roadmap.
- a documented way to have address ranges assigned automatically instead of hard-coded: we have some existing in-flight work on this; that needed to be adjusted already, so we’ll try to merge this into that.
- the ability to set up models and applications too: outside of things like setting up storage, we don’t see this as Concierge’s job - it makes more sense to do it with Terraform or in the tests using Jubilant.
- a GitHub Action: this would just be doing
sudo snap install -- classic concierge; sudo concierge prepare, so it’s not clear what value would be provided, in exchange for all the overhead of an action. Please reach out if we’re missing something.
The Pebble feature requests were:
- proper secrets support: on the 27.04 draft roadmap.
- scheduled jobs that aren’t expressed as backoffs: on the 27.04 draft roadmap.
Two other Pebble points that came up:
- the long-lived “pebble on machines” question. We did some experimental work on this in 26.10 and that will continue in 27.04, but this probably needs to also make it onto the Juju roadmap, and it also interacts with other longer-term Ubuntu plans. This remains a goal, but one that we don’t have a timeframe for.
- some low-quality security scanners frequently have false positive detections with Pebble. This is an increasing problem for rocks, including the 26.04 Ubuntu rock, which includes (but doesn’t use) Pebble. In 27.04, we’ll work on changing our release processes to improve this.
In terms of contact between Charm Tech and other teams:
- Our AMA sessions didn’t stop, but they did get less frequent. We’re going to try to get back to a consistent fortnightly frequency in 27.04. That’s 1-2 per team per year. If you’d really like to get together to talk about something, you don’t have to wait for the AMA: please do reach out and we can set up something ad-hoc. We’ll also try to pick up the suggestions from the 26.04 survey that we didn’t get to, particularly around reminders.
- You gave us several ideas about what we could do during Engineering sprints. We’re planning on trying out some of these, so please stay tuned and watch the calendar for opportunities so that we can work with you to figure out what does and doesn’t work well. We’re still figuring out exactly what we’ll do, so no more details right now, sorry.
We talked about sharing the raw survey data (anonymising written comments by aggregating them and having an LLM rewrite them), but decided that it wouldn’t be fair to do this without asking you first. We’ll bring this up in the 27.04 survey.
Once again, many thanks to all of you that took the time to fill out the survey. It really does make a difference!