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

[Daniel Bidwell]

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? If
not, can I make the root disk larger? What are my options?

I have already cleared out kernel updates.

[Paul Gear]

Post by Daniel Bidwell
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".

Post by Daniel Bidwell
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.

Post by Daniel Bidwell
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

[John Meinel]

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
=:->

Post by Paul Gear

Post by Daniel Bidwell
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".

Post by Daniel Bidwell
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.

Post by Daniel Bidwell
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
https://code.launchpad.net/~paulgear/+git/cleanup
--
Regards,
Paul Gear
Site Reliability Engineer
Canonical - Information Systems
--
Juju mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/
mailman/listinfo/juju

[Daniel Bidwell]

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.

Post by John Meinel
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
=:->

Post by Paul Gear

Post by Daniel Bidwell
My juju controllers appear to be defaulting to a 10GB root disk.

I am

Post by Daniel Bidwell
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".

Post by Daniel Bidwell
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.

Post by Daniel Bidwell
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
https://code.launchpad.net/~paulgear/+git/cleanup
-- 
Regards,
Paul Gear
Site Reliability Engineer
Canonical - Information Systems
-- 
Juju mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman
/listinfo/juju

[Rick Harding]

Thanks for the added detail Daniel. Glad you got the resize worked out.

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.

Post by John Meinel
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
=:->

Post by Paul Gear

Post by Daniel Bidwell
My juju controllers appear to be defaulting to a 10GB root disk.

I am

Post by Daniel Bidwell
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".

Post by Daniel Bidwell
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.

Post by Daniel Bidwell
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
https://code.launchpad.net/~paulgear/+git/cleanup
--
Regards,
Paul Gear
Site Reliability Engineer
Canonical - Information Systems
--
Juju mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman
/listinfo/juju

--
--
Juju mailing list
https://lists.ubuntu.com/mailman/listinfo/juju