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

Respect wffc override for blank block disks #2917

Merged

Conversation

akalenyu
Copy link
Collaborator

@akalenyu akalenyu commented Oct 4, 2023

What this PR does / why we need it:
We currently don't support the wffc override for blank block disks,
while there may be some use cases where that is desired.

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 #2915

Special notes for your reviewer:

Release note:

BugFix: wffc override not respected for blank block disks

@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 Oct 4, 2023
@akalenyu akalenyu force-pushed the blank-wffc-import-false-succeeded branch from f7839c4 to 623248e Compare October 4, 2023 11:51
@kubevirt-bot kubevirt-bot added size/S and removed size/M labels Oct 4, 2023
Entry("[test_id:4972] with first consumer", true),
Entry("with bind immediate annotation", false),
)
It("Should create blank raw image for block PV", func() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code leftover, looks good otherwise. Thanks for the PR!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whoops thx

@akalenyu akalenyu force-pushed the blank-wffc-import-false-succeeded branch from 623248e to 9dc43b2 Compare October 4, 2023 12:16
pvc.GetAnnotations()[cc.AnnPodPhase] = string(corev1.PodSucceeded)
if err := r.updatePVC(pvc, log); err != nil {
return reconcile.Result{}, errors.WithMessage(err, fmt.Sprintf("could not update pvc %q annotation and/or label", pvc.Name))
if pvc.Status.Phase == corev1.ClaimBound {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I am not sure about this. We purposely mark the PVC succeeded in the blank block case regardless of if it is bound or not. This is so that KubeVirt won't think it can't use the PVC. Once we have a consumer kubernetes will bind the PVC and everything resolves itself.

This was pre-populator logic. Now I don't really see how populators would affect blank block volumes at all, since there is no population. Maybe I am missing something.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is so that KubeVirt won't think it can't use the PVC

KubeVirt should be fine with WFFC Pending PVCs/DV:
kubevirt/kubevirt#9812

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, so I am trying to understand why we want this particular check here. I don't think we even want to use populators, unless maybe pre-allocation is set to true.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is if we stop using populators with this flow, we're back at the doppelganger pod solution

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the blank volume without pre-allocation case, there is no need for the doppel ganger. It is 'populated' already considering there is nothing we have to do. It just gets bound when the VM starts, but it is still exactly the way we want it. With pre-allocation, I would expect our populator to attempt the pr-eallocation at the appropriate time.

Copy link
Collaborator Author

@akalenyu akalenyu Oct 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the blank volume without pre-allocation case, there is no need for the doppel ganger

Yeah but kubevirt is not aware of that, it starts it anyway

But generally, I see your points, plus the test I added is broken because immediate.bind with blank block disk
doesn't do anything. Have to take another look

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my case, the PVC is not in bound state. It is in WFFC.
If the issue is because I didn't enable HonorWaitForFirstConsumer feature gate, is there any side effect or behavior change of enabling this feature gate?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we've been going with this feature for quite a few releases now,
it basically means we respect WFFC binding by not creating any worker pods until PVCs get scheduled.

Is there any particular use case you have that would require bypassing WFFC behavior,
and bind PVCs randomly? Or will these blank disks be consumed by a VM?

@akalenyu
Copy link
Collaborator Author

akalenyu commented Oct 4, 2023

/hold

Taking a step back. This works with HonorWaitForFirstConsumer enabled creating a bind pod.
The only thing that is broken is using bind.immediate with block blank DVs (because no consumer will be created)
Maybe we should just document this? or should we create a dummy bind pod for that case?

@kubevirt-bot kubevirt-bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 4, 2023
@akalenyu akalenyu force-pushed the blank-wffc-import-false-succeeded branch from 9dc43b2 to e6e318e Compare October 9, 2023 17:06
@kubevirt-bot kubevirt-bot added size/M and removed size/S labels Oct 9, 2023
@akalenyu akalenyu changed the title Report succeeded phase for block blank import more accurately Respect wffc override for blank block disks Oct 9, 2023
@akalenyu
Copy link
Collaborator Author

akalenyu commented Oct 9, 2023

/hold cancel

@kubevirt-bot kubevirt-bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 9, 2023
@akalenyu
Copy link
Collaborator Author

akalenyu commented Oct 9, 2023

@lzang @awels PTAL

We currently don't support the wffc override for blank block disks,
while there may be some use cases where that is desired.

Signed-off-by: Alex Kalenyuk <akalenyu@redhat.com>
@akalenyu akalenyu force-pushed the blank-wffc-import-false-succeeded branch from e6e318e to 84500d0 Compare October 10, 2023 09:35
@awels
Copy link
Member

awels commented Oct 11, 2023

/lgtm

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Oct 11, 2023
@mhenriks
Copy link
Member

/approve

@kubevirt-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mhenriks

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 Oct 11, 2023
return reconcile.Result{}, errors.WithMessage(err, fmt.Sprintf("could not update pvc %q annotation and/or label", pvc.Name))
}
return reconcile.Result{}, nil
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get why this is not needed any more from looking at the CL. Could you please clarify why?
Does this logic work for both populator case and non-populator case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Essentially this was a short cut for one particular case (blank disk, no preallocation) and removing it will cause a pod to be created, but per the rest of this PR, that pod won't do anything. What it will do is follow the rest of the logic when creating a population pod, which should work for both populator and non populator cases, as well as HonorWaitForFirstConsumer set or not.

@kubevirt-bot kubevirt-bot merged commit 02af1da into kubevirt:main Oct 11, 2023
18 checks passed
@akalenyu
Copy link
Collaborator Author

akalenyu commented Apr 8, 2024

/cherrypick release-v1.57

@kubevirt-bot
Copy link
Contributor

@akalenyu: new pull request created: #3170

In response to this:

/cherrypick release-v1.57

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.

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/M
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Blank disk with block volume mode stuck in ImportScheduled for WFFC storage class
6 participants