Allow way to update application storage (constraint?)

This is tricky because you could envisage in the general case that not all storage backends would allow the allocated size to be changed post deploy. And if they did, could that be done in place or would the volume need to be stopped and/or detached first etc. I think for now you'd just need to spin up a new unit with the desired storage and run a charm action to migrate the data across and then remove the original unit.

On Tue, Oct 13, 2020 at 02:57:49AM -0000, Ian Booth wrote:
> This is tricky because you could envisage in the general case that not
> all storage backends would allow the allocated size to be changed post
> deploy. And if they did, could that be done in place or would the volume
> need to be stopped and/or detached first etc. I think for now you'd just
> need to spin up a new unit with the desired storage and run a charm
> action to migrate the data across and then remove the original unit.
>

How about we don't change it for units already deployed but rather an
option to change the storage size used for new units? This saves the
need to tear down the entire juju application to redeploy it with a
larger storage volume size.

This caught us where two new units were added but only had 100GiB storage. Had to manually resize the disks via the Azure Portal UI.

Does `juju upgrade-charm ubuntu-repository-cache --storage ubuntu-repository-cache=256G` work per documented[1]? So future `juju add-unit` would create units with 256GiB storage rather than 100GiB?

This was with a model running Juju 2.9.34 (maybe .33).

[1] https://juju.is/docs/olm/defining-and-using-persistent-storage#heading--upgrading-charms

Yes, it's supposed to work that way - new units get whatever store has been specified at the time.
If there's an issue, we'll fix it.

Is there a way to update it without having to redeploy the application? Does 'juju upgrade-charm ubuntu-repository-cache --storage ubuntu-repository-cache=256G' do that so new units will get 256GiB instead of 100GiB?

Currently the only way to change the storage constraints associated with an application is to use upgrade-charm --storage. We have a command set-constraints to update an application's constraints. I think we want a set-storage command to do the same thing for storage updates.

Yes, having a command such as `set-storage` would be helpful. I've gone around using `upgrade-charm --storage` so hopefully we don't run into this again for our existing cloud mirrors.

We also want a way to disable storage too, as per recently when migrating an application postgresql DB from PS4.5 to PS5. The application was originally deployed with storage but there wasn't any way to remove it (we wanted local storage over ceph volumes for faster I/O).

The only way was to removing the application and redeploying.