Bug 2134213
| Summary: | [RFE] leapp should adjust the OVL size based on partitions and package installations. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | jcastran |
| Component: | leapp-repository | Assignee: | Petr Stodulka <pstodulk> |
| Status: | ON_QA --- | QA Contact: | upgrades-and-conversions |
| Severity: | urgent | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.9 | CC: | kwalker, pstodulk |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | leapp-repository-0.18.0-5.el7_9 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Hi John, thank you for the report. I am lowering severity and priority (it's not a blocking customers, it's documented in the official upgrade documentation, and it's rfe).
Regarding the provided msg, we have already opened PR in upstream to improve it:
https://github.com/oamg/leapp-repository/pull/956
We are working on improvements in this area continuously (see related bzs below).
Related BZs:
https://bugzilla.redhat.com/show_bug.cgi?id=2110045
https://bugzilla.redhat.com/show_bug.cgi?id=1832730
https://bugzilla.redhat.com/show_bug.cgi?id=1871076
Additional info:
This is not a duplicate of mentioned bugs as the requested solution
is to automatically increase the size of the underlying images
in a safe way (so not all space is consumed) which is not part
of the other bugs.
Any other improvements in this area should first introduce a better
solution that does not consume 2GiB + 2GiB per partition formated
with XFS without ftype attributes.
@Petr I raised the Severity back up. It is an exceptionally severe problem, even if just as reported by Support Delivery. I left the Priority to reflect your teams evaluation of the BZ/RFE. The error message improvement looks great! I can also see how it could be seen as an RFE versus a BZ. I would lean more heavily in the direction of a BZ though. Primarily in that the current implementation is completely static where the input factors are dynamic. The tool doesn't attempt to figure out how much space is necessary at all, it just creates a 2Gib overlay mount... The tooling has access to an approximate amount of space necessary to install. With the transaction prepared, simply verify the installed RPMs size. It seems pretty straightforward to me to simply calculate the necessary size and then add a bit of overhead on top. You should have a reasonable idea of what the size should be, which could then be overridden in the event of a corner-case. The original solution has been redesigned and should be fixed by upstream PR: https://github.com/oamg/leapp-repository/pull/1097 All created OVL images are represented by sparse-files now. In many cases it should mean less consumed space and all previous problems with too greedy OVL images should be fixed. However for systems without old XFS filesystems and many partitions will be requirements higher - approx 128 MB per partition/volume specified in fstab. This value could be possibly yet lowered, but for now let's go with this. |
~~~~~~~~~~~~~~~~ Description of problem: ~~~~~~~~~~~~~~~~ Currently leapp defaults to a 2GB LEAPP_OVL_SIZE (overlay size) which often results in: At least 1044MB more space needed on the / filesystem. This can occur for 1 of two reasons - Not enough physical space on the system - Not enough space in the overlay fs for the packages being installed. For customers who have ftype=0 xfs partitions, it means the system has 2GB to install the sometimes 1500+ packages on a system. - - - - - - - - - Secondarily, leapp does not verify or make it clear the overlay's it's going to make or how much space will be consumed in /var. ~~~~~~~~~~~~~~~~ Recommended Resolution: ~~~~~~~~~~~~~~~~ * The logic could be improved to determine a better rough estimate of space needed for packages, then automatically increase the size of LEAPP_OVL_SIZE for the upgrade. * It should also verify that there is enough space in /var/lib/leapp to hold all of the overlay images that leapp is going to create. If either of these is not possible, there should be a clear message telling the customer (And the engineers) what the issue is. a LEAPP_OVL_SIZE of 4096 is recommended for this upgrade based on your partitioning layout. This requires 20GB in /var/lib/leapp . Currently only 15GB is free. Free up space in $(df -h /var/lib/leapp), or create a dedicated /var/lib/leapp partition over 20GB in size to hold the recommended overlays for this upgrade. ~~~~~~~~~~~~~~~~ Note ~~~~~~~~~~~~~~~~ This is the number one issue with leapp that I see. Most of the time it results in making a dedicated /var/lib/leapp partition, and increasing LEAPP_OVL_SIZE by 1GB until it has enough space for all the packages being installed. [leapp] At least X MB more space needed on the </XXX> filesystem https://access.redhat.com/solutions/5057391