Background
In #15025, we bumped the /usr partition size in several RHEL 8 anssi_bp28_* kickstart files (intermediary, enhanced, high) to fix disk space failures during stabilization testing:
logvol /usr --fstype=xfs --name=usr --vgname=VolGroup --size=6667 --fsoptions="nodev"
→
logvol /usr --fstype=xfs --name=usr --vgname=VolGroup --size=6800 --fsoptions="nodev"
During review, @comps noted that the historical practice of keeping our kickstarts within a 20 GB total disk footprint was a limitation of the Contest test infrastructure, not a documented requirement of the project. That limitation was fixed in RHSecurityCompliance/contest#559, and Contest now provisions disks with 100 GB of virtual space (expandable further if needed).
Problem
Our kickstart files under products/<product>/kickstart/ serve (at least) two different purposes that have gotten conflated:
- Test fixtures for stabilization/CI runs (e.g., via Contest) — previously constrained to fit within 20 GB.
- Reference examples shipped to customers, who may use them as a starting point for their own installs. For this use case, partition sizes double as minimum recommended sizes to guide RHEL installs.
Because of (1), partition sizes (like /usr above) have been kept artificially tight, leading to repeated one-off bumps (e.g., "add a few more MB") whenever a package set grows and a test starts failing on disk space.
Proposal
Now that the 20 GB test-infra constraint no longer applies, revisit the sizing strategy for upstream kickstart files:
- Decide whether kickstarts should be restructured with more generous default partition sizes/reserves, reducing the frequency of these disk-space-driven patches.
- Clarify (in docs/comments) which purpose (test fixture vs. customer-facing example) drives the sizing for each kickstart, since the two use cases can pull in different directions.
References
Background
In #15025, we bumped the
/usrpartition size in several RHEL 8anssi_bp28_*kickstart files (intermediary,enhanced,high) to fix disk space failures during stabilization testing:→
During review, @comps noted that the historical practice of keeping our kickstarts within a 20 GB total disk footprint was a limitation of the Contest test infrastructure, not a documented requirement of the project. That limitation was fixed in RHSecurityCompliance/contest#559, and Contest now provisions disks with 100 GB of virtual space (expandable further if needed).
Problem
Our kickstart files under
products/<product>/kickstart/serve (at least) two different purposes that have gotten conflated:Because of (1), partition sizes (like
/usrabove) have been kept artificially tight, leading to repeated one-off bumps (e.g., "add a few more MB") whenever a package set grows and a test starts failing on disk space.Proposal
Now that the 20 GB test-infra constraint no longer applies, revisit the sizing strategy for upstream kickstart files:
References
qcow2disks RHSecurityCompliance/contest#559 (fix that raised Contest's disk size to 100 GB)