Allow way to update application storage (constraint?)

[Haw Loeung]

Hi,

When deploying an application, with say the following defined storage parameters:

$ juju export-bundle

| applications:
| ubuntu-repository-cache:
| storage:
| ubuntu-repository-cache: azure,100G

Storage volumes are created as follows:

| $ juju list-storage
| Unit Storage id Type Pool Size Status Message
| ubuntu-repository-cache/1 ubuntu-repository-cache/1 filesystem azure 100GiB attached
| ubuntu-repository-cache/2 ubuntu-repository-cache/2 filesystem azure 100GiB attached

Unfortunately, there doesn't appear to be a way to change this. Not for existing units nor for new units. In my case, I want to increase this to 256GiB. I understand that you can only increase this via the UI/API for existing units when they are not running/started.

[Ian Booth (wallyworld)]

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.

[Haw Loeung (hloeung)]

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.

[Haw Loeung (hloeung)]

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

[Ian Booth (wallyworld)]

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.

[Haw Loeung (hloeung)]

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?

[Ian Booth (wallyworld)]

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.

[Haw Loeung (hloeung)]

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.

[Haw Loeung (hloeung)]

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.