MAAS is distributed as a snap, and has recently introduced the idea of a ‘deprecation notice’, inspired by https://snapcraft.io/docs/deprecation-notices.
MAAS is complicated software and there are several different ways it can be setup. As an example of when we create a deprecation notice (DN), the development team wants to remove an option of running the database in the snap (since it’s hard to scale and distribute) - this requires actions by the operator to migrate. We have a version of the software that can know that it’s setup in a deprecated way, and want to encourage operators to migrate away to a supported option before we remove the old way.
We plan to expose DNs in the (web) UI, but also want to reach our CLI users and wonder how snapd can help us, if at all. One idea is Warnings, but that seems to be limited to snapd itself? So then we looked at Health Checks but that doesn’t seem to quite fit - there’s no clean fit for the concept of “software is all ok for now, but operator needs to do something before they can move to a future version”.
As a reminder, this is what snapctl set-health --help has right now
status can be one of:
- okay: the snap is healthy. This status takes no message and no code.
- waiting: a resource needed by the snap (e.g. a device, network, or service) is
not ready and the user will need to wait. The message must explain what
resource is being waited for.
- blocked: something needs doing to unblock the snap (e.g. a service needs to be
configured); the message must be sufficient to point the user in the right
direction.
- error: something is broken; the message must explain what.
We basically need the idea of ‘going-to-be-blocked’ (strawman, suggestions welcome!).
Has anyone else solved this or a similar issue?