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