-
Notifications
You must be signed in to change notification settings - Fork 267
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
Respect wffc override for blank block disks #2917
Conversation
f7839c4
to
623248e
Compare
tests/import_test.go
Outdated
Entry("[test_id:4972] with first consumer", true), | ||
Entry("with bind immediate annotation", false), | ||
) | ||
It("Should create blank raw image for block PV", func() { |
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whoops thx
623248e
to
9dc43b2
Compare
pkg/controller/import-controller.go
Outdated
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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
/hold Taking a step back. This works with HonorWaitForFirstConsumer enabled creating a bind pod. |
9dc43b2
to
e6e318e
Compare
/hold cancel |
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>
e6e318e
to
84500d0
Compare
/lgtm |
/approve |
[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 |
return reconcile.Result{}, errors.WithMessage(err, fmt.Sprintf("could not update pvc %q annotation and/or label", pvc.Name)) | ||
} | ||
return reconcile.Result{}, nil | ||
} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
/cherrypick release-v1.57 |
@akalenyu: new pull request created: #3170 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:
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: