auto-upgrade charms

[Andrea Ieri]

One of the major bottlenecks of managing a large fleet of environments is rolling out charm upgrades in a timely fashion, given that there is no overarching multi-controller / multi-model orchestration.

It is my belief that in the long term it would be beneficial for charms to autoupgrade on their own by default just like snaps, but it's clear that for a large set of existing charms autoupgrades would be terribly disruptive at this stage. At the same time, there is also already a set of auxiliary/monitoring charms that operators want to keep as up to date as possible and are generally safe to upgrade (e.g. prometheus exporters, juju-lint, the COS charms, nrpe, etc).

I would therefore want to propose juju controllers take care of periodically upgrading selected charms whenever upgrades are available (for a given channel).

Applications would of course have to opt in, and it should be possible to define a time window (in order to match existing maintenance windows for the specific environments).

For example, a possible implementation could consist of a default charm config "auto-refresh=true/false" that would default to false for all charms that don't declare it in their config.yaml. This would still allow charm authors to set their charms to a different default, as well as let operators enable/disable the functionality on a per-application basis. A further model config option could be used to specify when the refresh should occur.

A positive additional side-effect of the above would be to make it easy to create testing / preprod environments by having them be composed of applications that are both enlisted into auto-upgrades and track candidate or edge channels.

[Simon Aronsson (0x12b)]

This is something we'd also like to see for COS, mainly to accommodate easier operations for the managed services team.

[Tom Haddon (mthaddon)]

IS would also be interested in a mechanism for upgrading charms automatically, although whether that should be managed by Juju itself or some external mechanism/system is a difficult question. Should this be something JAAS does? Or Landscape?

[Andrea Ieri (aieri)]

Although either a built-in or external solution could yield identical results in the short term, I believe having this functionality be provided by juju itself would be beneficial in the longer term since it would nudge charm authors to consider safe and frequent upgrades as a standard thing they are supposed to provide. On the other hand, I suspect that if periodic upgrades were to be provided by an external tool like landscape the number of charms that could safely be refreshed whenever a new version is published would not significantly increase over time.

[Andrea Ieri (aieri)]

To expand on "it should be possible to define a time window (in order to match existing maintenance windows for the specific environments)", I wanted to note the snapd timer string spec[0] as it may be reused to define when autorefreshes should occur, further standardizing on the UX.

[0] https://snapcraft.io/docs/timer-string-format