How do you clean a juju disk or make it larger?

Daniel Bidwell drbidwell at gmail.com
Wed Jun 13 13:35:36 UTC 2018


My case was using VmWare as the cloud.  The controllers defaulted to
10GB.  I am running juju 2.3.8.  I have about 12 vm's on the controller
with about 24 locally written charms.  /var/lib/juju/db is currently
using 8.3GB.

The simplest solution for me was to increase the root disk size and
reboot the controller.  The cloud-init process resized the partition to
fill the rest of the disk and then resized the file system to fill the
enlarged partition.

I am not concerned about the size so much as I needed to finish
deploying my spread of servers.

I did clean out a group of old kernels that had accumulated as well as
old versions of juju that I had upgraded from, but those were
incidental.

I posted the question and solution to askubuntu.com so others could
find the answer easily if they hit the same problem.

On Wed, 2018-06-13 at 16:06 +0400, John Meinel wrote:
> IIRC older Juju used the default EC2 settings, which gave 8GB hard
> drives, but newer should default to 32GB disks. I'm not sure how that
> varies across all providers, though.
> 
> Note that you should always be able to bootstrap with a custom root-
> disk constraint. eg "juju bootstrap --bootstrap-constraints root-
> disk=32G"
> 
> As for issues about the disk filling up, it would be good to have a
> bit more information about what juju version, what types of workloads
> you're deploying, etc. The data might be stale charm binaries that
> are being cached by the server, or if it is Juju 1.X then it could be
> image caches, or transaction log issues, etc.
> 
> John
> =:->
> 
> On Tue, Jun 12, 2018 at 9:12 AM, Paul Gear <paul.gear at canonical.com>
> wrote:
> > On 11/06/18 01:47, Daniel Bidwell wrote:
> > > My juju controllers appear to be defaulting to a 10GB root disk.
> > I am
> > > running out of disk space on the controller. I have 6.7GB in 
> > > /var/lib/juju/db. Is there a way to reduce the disk usage on
> > this?
> > 
> > I think perhaps this is worth logging as a wishlist bug. A long-
> > running
> > production juju controller should never be deployed with a disk
> > that
> > small (our largest production cluster is already a little
> > uncomfortable
> > with 50 GB), and juju doesn't really distinguish between "this is a
> > CI
> > controller that's only going to be up long enough to run my test
> > suite"
> > and "this is going to run all of my production OpenStack VMs for
> > the
> > next year". It would be nice if you could tell it "size the
> > controller
> > for N live models".
> > 
> > > If not, can I make the root disk larger? What are my options?
> > 
> > That all depends on your underlying cloud infrastructure.  I
> > believe
> > some providers (e.g. GCE) make this really easy.
> > 
> > > I have already cleared out kernel updates.
> > 
> > Not directly related to juju controller sizing, but relevant to the
> > above: I've been working on a little tool that handles many of the
> > common scenarios we encounter, including kernel updates and other
> > tools
> > you may or may not use.  It's alpha quality; feedback & patches
> > gratefully accepted:
> > 
> > https://code.launchpad.net/~paulgear/+git/cleanup
> > 
> > -- 
> > Regards,
> > Paul Gear
> > Site Reliability Engineer
> > Canonical - Information Systems
> > 
> > 
> > -- 
> > Juju mailing list
> > Juju at lists.ubuntu.com
> > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman
> > /listinfo/juju
> > 
-- 
Daniel Bidwell <drbidwell at gmail.com>




More information about the Juju mailing list