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
Do not factor fs overhead into available space during validation #2195
Conversation
Inlining my rationale for closing #2194, alternate proposal to use statfs Bfree (and still account for FS overhead): Most users who want just barely big enough DVs are using the storage API (it's mostly vm-import-operator), which already pads their size requests to be big enough. |
Here message needs to be fixed:
New test needs image in images directory. |
other tests still need investigation |
test 2329 is also about different warning/error message |
This image size and filesystem overhead combination was experimentally determined to reproduce bz#2064936 in CI when using ceph/rbd with a Filesystem mode PV since the filesystem capacity will be constrained by the PVC request size. Below is the problem it tries to recreate: When validating whether an image will fit into a PV we compare the image's virtual size to the filesystem's reported available space to guage whether it will fit. The current calculation reduces the apparent available space by the configured filesystem overhead value but the overhead is already (mostly) factored into the result of Statfs. This causes the check to fail for PVCs that are just large enough to accommodate an image plus overhead (ie. when using the DataVolume Storage API with filesystem PVs with capacity constrained by the PVC storage request size). This was not caught in testing because HPP does not have capacity constrained PVs and we are typically testing block volumes in the ceph lanes. It can be triggered in our CI by allocating a Filesystem PV on ceph-rbd storage because these volumes are capacity constrained and subject to filesystem overhead. Signed-off-by: Bartosz Rybacki <brybacki@redhat.com>
Corrects the validation logic for target volume. Below description of the original problem: When validating whether an image will fit into a PV we compare the image's virtual size to the filesystem's reported available space to guage whether it will fit. The current calculation reduces the apparent available space by the configured filesystem overhead value but the overhead is already (mostly) factored into the result of Statfs. This causes the check to fail for PVCs that are just large enough to accommodate an image plus overhead (ie. when using the DataVolume Storage API with filesystem PVs with capacity constrained by the PVC storage request size). This was not caught in testing because HPP does not have capacity constrained PVs and we are typically testing block volumes in the ceph lanes. It can be triggered in our CI by allocating a Filesystem PV on ceph-rbd storage because these volumes are capacity constrained and subject to filesystem overhead. Signed-off-by: Bartosz Rybacki <brybacki@redhat.com>
Removed redundant and misleading part about pvc size and update the simplification Signed-off-by: Bartosz Rybacki <brybacki@redhat.com>
The test checks that the validation logic takes fs Overhead into account. New validation logic does not check fs overhead. So test is no longer relevant. Signed-off-by: Bartosz Rybacki <brybacki@redhat.com>
/retest |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: awels The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/cherrypick release-v1.43 |
@awels: once the present PR merges, I will cherry-pick it on top of release-v1.43 in a new PR and assign it to you. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/test pull-containerized-data-importer-e2e-k8s-1.21-hpp |
@awels: #2195 failed to apply on top of branch "release-v1.38":
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@awels: new pull request created: #2198 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
What this PR does / why we need it:
This is the continuation of #2193
When validating whether an image will fit into a PV we compare the
image's virtual size to the filesystem's reported available space to
guage whether it will fit. The current calculation reduces the apparent
available space by the configured filesystem overhead value but the
overhead is already (mostly) factored into the result of Statfs. This
causes the check to fail for PVCs that are just large enough to
accommodate an image plus overhead (ie. when using the DataVolume
Storage API with filesystem PVs with capacity constrained by the PVC
storage request size).
This was not caught in testing because HPP does not have capacity
constrained PVs and we are typically testing block volumes in the ceph
lanes. It can be triggered in our CI by allocating a Filesystem PV on
ceph-rbd storage because these volumes are capacity constrained and
subject to filesystem overhead.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #
bz#2064936.
Special notes for your reviewer:
This is the continuation of #2193
Trying to cleanup, remove unwanted changes, verify tests.
Release note: