juju does not allow a persistent storage block for the controller disk

[Richard Harding]

Running a Juju controller at scale requires a large chunk of disk. The charms, resources, and potentially lxd images in the near future, grow over time and eat up disk space over time.

To handle this, a large production controller needs the ability to stick the mongo storage or the entire machine onto a persistent storage block assigned from swift or ceph. This needs to be part of the bootstrap UX and should be migratable if a controller grows over time from a non-persistent store and the user wants to move to a persistent store.

[Anastasia (anastasia-macmood)]

Persistent storage is on the roadmap this cycle.
Removing 2.1 milestone as we will not be addressing this issue in 2.1.

[Sandor Zeestraten (szeestraten)]

Any plans for this?

[Sandor Zeestraten (szeestraten)]

How's the roadmap looking for this?

[Tom Haddon (mthaddon)]

This would be addressed by having a charm for a juju controller, wouldn't it (depending on how that is implemented)? I believe there are plans for this underway but not sure of timeline.

[Ian Booth (wallyworld)]

Added to support Azure encrypted disks is the ability to set up the controller machine root disk.

see this post for details that can be adapted for other providers, eg ebs volume for AWS etc

https://discourse.charmhub.io/t/juju-2-9-new-azure-features-disk-encryption-byo-vnets-public-ip-constraint/4030