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

Bug #1631138 reported by Richard Harding
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
juju
Triaged
High
Unassigned

Bug Description

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.

Tags: canonical-is
Revision history for this message
Anastasia (anastasia-macmood) wrote :

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

Changed in juju:
milestone: 2.1-rc2 → none
Revision history for this message
Sandor Zeestraten (szeestraten) wrote :

Any plans for this?

Revision history for this message
Sandor Zeestraten (szeestraten) wrote :

How's the roadmap looking for this?

Revision history for this message
Tom Haddon (mthaddon) wrote :

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.

Revision history for this message
Ian Booth (wallyworld) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers