-
Notifications
You must be signed in to change notification settings - Fork 59
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
Root Filesystem Expansion #570
Comments
I think using Ignition is a tough sell here. Ignition is config-driven, but the config is no longer available and wouldn't help us if it was, since the system may have changed since initial provisioning. And the task is neither first-boot nor provisioning. If we want to avoid bash, writing a new tool makes sense to me. |
I think we do want two tools...but they really need to share as much code as is feasibly possible. One simple implementation of that would be to have the logic in the ignition binary and we have a wrapper which calls out to it. Another is to make it a Go shared library. But the more I think about it...it'd be great to use systemd-repart. If it comes to it...we could try fighting to get that backported to RHEL8 systemd too. |
But...let me lay out an argument here that the For "day 2 resize"...I have come around to the idea that this should require a manual invocation (as I think jlebon mentioned), because the user might want to use the new space for a separate partition. It would be great to handle "day 2" resizes for the case of LUKS + [filesystem] though for sure out of the box. |
Hmm, please do; that's not obvious to me. Ignition doesn't currently have any functionality for resizing partitions or filesystems, and doesn't know what the root device is. (Also, a change in default behavior technically requires a spec bump to version 4.0.0, though I think it's arguable because the OS-level behavior would be unchanged.) At the moment the separate resize script makes more sense to me. |
I like the idea of a wrapper that calls out to the Ignition binary. It allows us to bake in the functionality in Ignition itself, doesn't require us to package/ship an entirely new binary, and allows us to easily share the feature across FCOS + RHCOS (once RHCOS is using spec v3).
In the manpage,
So maybe it would be a good fit for initial install/configuration, but doesn't seem like the right tool for day 2 resize operations. |
I guess I'm still missing something here. Why is that good? What Ignition functionality is useful for implementing this feature? |
It knows how to create partitions though, resizing is pretty straightforward relatively. I am not arguing Ignition should know about growing filesystems (see above) - if we're reprovisioning the rootfs then we're implicitly sizing to the target blockdev (which, if we're doing it "in place", then Ignition growing the root partition would work). |
Or to say this all another way: For the case of "reprovision rootfs in place", it's bonkers to separately growpart + resize, because we just created that filesystem; we might as well create it in the desired layout to start. (I believe it's also more efficient for many Linux filesystems to start out at a reasonable approximation of their target size) |
Nope, the fault is mine. I attached myself to the idea of landing functionality in Ignition without thinking through the use case. Imagining a system being ignited and doing a grow partition operation during that phase is...well, wrong. As Colin points out above, Ignition will have just created the partition table and filesystem...why would it need to grow a partition immediately after creation? I guess that means we need Something Else ™️ to handle a day 2 resize operation. Perhaps another tool that can leverage a shared library is the better path. |
With coreos/ignition#1087 we can document that the user should request partition resizing, and then the created filesystem will have the correct size immediately. As to day 2 resizing: if we don't want to continue implementing in shell, we could put it in rdcore, which already includes a lot of block device support code. Presumably it's easier to do resizing from the initramfs before the root is mounted. However, if resize is a manual operation, we'd need some way to cause it to be invoked. If instead we want resize to run from userspace, we could consider adding yet another binary to the coreos-installer repo. |
Ignition is responsible for parition setup on first boot and currently does not use systemd-repart. See also coreos/fedora-coreos-tracker#570
Ignition is responsible for partition setup on first boot and does not use systemd-repart currently. See also coreos/fedora-coreos-tracker#570
Ignition is responsible for partition setup on first boot and does not use systemd-repart currently. See also coreos/fedora-coreos-tracker#570
Ignition is responsible for partition setup on first boot and does not use systemd-repart currently. See also coreos/fedora-coreos-tracker#570
Disable the enabled by default systemd-repart.service unit as Ignition is responsible for partition setup on first boot and does not use systemd-repart currently. See also coreos/fedora-coreos-tracker#570
Mask the enabled by default systemd-repart.service unit as Ignition is responsible for partition setup on first boot and does not use systemd-repart currently. See also coreos/fedora-coreos-tracker#570
Mask the enabled by default systemd-repart.service unit as Ignition is responsible for partition setup on first boot and does not use systemd-repart currently. See also coreos/fedora-coreos-tracker#570
Related discussions about this in #586. |
Circling back to this, so the situation now is that So this issue now is strictly about supporting root filesystem growing as a day-2 manual operation. This tool would of course need to be smarter than just what's in I'd be in favour of a new binary (as mentioned above, possibly in |
Do you have any forecast when we will have this feature in CoreOS? |
No concrete plans right now. @jlebon from your summary above do I read right that what's missing here is a tool (that handles complex root devices) a user can run manually to resize the rootfs after the initial boot. |
Yup, exactly. This work is tracked internally as well, but is not yet scheduled for a specific timeline. Assigning to @sohankunkerkar to reflect the internal state. |
FTR I briefly looked into this; as of RHEL9 |
Definitely would be nice to centralize on |
Mask the enabled by default systemd-repart.service unit as Ignition is responsible for partition setup on first boot and does not use systemd-repart currently. See also coreos/fedora-coreos-tracker#570
Mask the enabled by default systemd-repart.service unit as Ignition is responsible for partition setup on first boot and does not use systemd-repart currently. See also coreos/fedora-coreos-tracker#570
Issue
Now that we have LUKS volumes & the ability to reprovision the root filesystem coming soon we need to be able to handle expanding the root partition in those cases. Currently we are doing the expansion via
coreos-growpart
but that only handles the most basic case without any support for complex device types and is only inside of the initramfs. It would also be nice to provide a way for users to expand root after the first boot (especially for platforms like VMware which can easily resize the underlying disks).Potential Solutions
coreos-growpart
code to support the new casesThe text was updated successfully, but these errors were encountered: