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

[release-v1.57] Backport profile tunings for several provisioners #3229

Merged

Conversation

akalenyu
Copy link
Collaborator

@akalenyu akalenyu commented May 2, 2024

What this PR does / why we need it:

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 #
https://issues.redhat.com/browse/CNV-41450

Special notes for your reviewer:

Release note:

Update portworx CSI to have CSI-clone clone strategy
LVMS tuned to default to CSI clones & snapshot dataimportcron sources
Trident ONTAP tuned to default to snapshot clone strategy & snapshot dataimportcron sources

ShellyKa13 and others added 3 commits May 2, 2024 11:23
Signed-off-by: Shelly Kagan <skagan@redhat.com>
Following some investigation we are now confident this tuning is benefical for LVMS:
- CSI clone is effectively implemented the same as snapshotting because both already use lvm2 thinly provisioned snapshots under the hood
- Snapshots being COW, it makes total sense to store cron sources in the snapshot format instead of PVC:
```
A snapshot of a thin logical volume also creates a thin logical volume.
This consumes no data space until a COW operation is required, or until the snapshot itself is written.
```

Signed-off-by: Alex Kalenyuk <akalenyu@redhat.com>
There's a bug in the trident CSI driver that causes a snapshot
to be left over following each CSI clone:
NetApp/trident#901
This is becoming a problem rapidly once one hits the snapshot limit per volume (golden image):
https://kb.netapp.com/onprem/ontap/os/Maximum_number_of_snapshots_supported_by_ONTAP

Signed-off-by: Alex Kalenyuk <akalenyu@redhat.com>
@kubevirt-bot kubevirt-bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. labels May 2, 2024
@kubevirt-bot kubevirt-bot requested review from aglitke and alromeros May 2, 2024 08:24
@akalenyu
Copy link
Collaborator Author

akalenyu commented May 2, 2024

/test pull-containerized-data-importer-e2e-ceph

@awels
Copy link
Member

awels commented May 2, 2024

/lgtm
/approve

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label May 2, 2024
@kubevirt-bot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kubevirt-bot kubevirt-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 2, 2024
@kubevirt-bot kubevirt-bot merged commit 35521b6 into kubevirt:release-v1.57 May 2, 2024
9 of 10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/S
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants