Thanks for the added detail Daniel. Glad you got the resize worked out. On Wed, Jun 13, 2018 at 9:36 AM Daniel Bidwell <drbidw...@gmail.com> wrote:
> 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 >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
