Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create_disk: Support rootfs-size #917

Closed
wants to merge 1 commit into from

Conversation

cgwalters
Copy link
Member

For RHCOS with encryption, we encrypt in early boot, and it's beneficial
if the root filesystem size is small initially - distinct from the
"default disk" size that applies in clouds (and libvirt).

This helps RHCOS maintain its default 16G size for libvirt without
requiring the installer and other tools to start resizing it.

For RHCOS with encryption, we encrypt in early boot, and it's beneficial
if the root filesystem size is small initially - distinct from the
"default disk" size that applies in clouds (and libvirt).

This helps RHCOS maintain its default 16G size for libvirt without
requiring the installer and other tools to start resizing it.
@cgwalters
Copy link
Member Author

Alternatively...we could use the same space estimation we do for metal across the board by default.

@cgwalters
Copy link
Member Author

One benefit/downside of this is that we'd start always having coreos-growpart.service expand on boot, even in qemu.

@cgwalters
Copy link
Member Author

Or maybe we should do the "size estimation" even for qemu.

@jlebon
Copy link
Member

jlebon commented Nov 15, 2019

Just making sure I follow here. On bare metal, we growpart to the size of the actual disk. On clouds, we growpart to the size of the allocated disk. So it's only on qemu/libvirt that the number we put in size is used as is, correct? I'm confused from openshift/installer#2652 (comment) why the installer isn't doing the resize itself since it's the equivalent of choosing the storage size on clouds (which it already does today).

Anyway, as to the rootfs itself, I like the idea of being consistent everywhere (using size estimation). (It also makes it easier to add more partitions after the rootfs via Ignition for testing.)

@cgwalters
Copy link
Member Author

Anyway, as to the rootfs itself, I like the idea of being consistent everywhere (using size estimation). (It also makes it easier to add more partitions after the rootfs via Ignition for testing.)

Yeah I'm working on this.

(It also makes it easier to add more partitions after the rootfs via Ignition for testing.)

A bit, but you can also just cosa run --size 26 for that too.

@cgwalters
Copy link
Member Author

Don't need this anymore.

@cgwalters cgwalters closed this Nov 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants