allow charms to decline scale-application requests

[Paul Collins]

Not all scaling requests make sense.

For example, when scaling Mattermost it should be done with clustering enabled, which requires a licence.

And when scaling ceph-mon, it is strongly advised (but not strictly mandatory) for the number of units to be odd: https://docs.ceph.com/en/latest/rados/operations/add-or-rm-mons/#adding-monitors

It’d be nice if the user got some kind of feedback if they try to scale the application without meeting such requirements or recommendations.

Perhaps there could be a --force flag that is also passed to the charm to let it know that the operator is aware of the situation and wishes to proceed anyway.

In the ceph-mon case, it could log loudly and then accept. Mattermost would probably reject even a forced request, and there are probably other services where this is the thing to do.

[Pen Gale (pengale)]

Adding to wishlist and tagging w/ field-feedback so that it doesn't get lost in the shuffle.

I like this idea a lot.

[Tom Haddon (mthaddon)]

I'd like this for the nginx-ingress-integrator charm, fwiw. It's a "proxy" charm in the sense that it doesn't run a workload, it just interacts with the k8s api, and there's no reason to have more than one unit.

[Tom Haddon (mthaddon)]

This would also be useful for a case where you have a charm that's executing a task such as synchronising content. We're in the process of spec-ing out such a charm at the moment, and having a way to say "this charm should only have one unit" would greatly simplify charm logic.

[Andrew Scribner (ca-scribner)]

Many Kubeflow charms would benefit from this too. For some, we deploy workloads that horizontally scale themselves and scaling in juju wouldn't make sense. For others, we just haven't implemented scaling so it would be bad if the user scaled things.