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.g...@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@lists.ubuntu.com > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman > > /listinfo/juju > > -- Daniel Bidwell <drbidw...@gmail.com> -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
