allow charms to decline scale-application requests

Bug #1901964 reported by Paul Collins on 2020-10-29
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
juju
Wishlist
Unassigned

Bug Description

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.

Pete Vander Giessen (petevg) wrote :

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

I like this idea a lot.

Changed in juju:
status: New → Triaged
importance: Undecided → Wishlist
tags: added: field-feedback
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers