Closed orelmisan closed 3 months ago
Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all
/cc @acardace @stu-gott
@RobertKrawitz Could you please have a look?
@ingvagabund Could you please have a look?
If I understand it correctly, this alone will not solve the descheduler problem; this is just one piece of the puzzle. Correct?
Thank you for the feedback @RobertKrawitz. I was hoping to understand from you whether this design would solve the descheduler problem. What are the gaps that you see?
AFAIU from my discussions with @stu-gott, the agreement was:
descheduler.alpha.kubernetes.io/request-evict-only
annotation to all virt-launcher
pods.descheduler.alpha.kubernetes.io/eviction-in-progress
annotation to virt-launcher
pods which received the eviction request and will be migrated from the node because of it.If I understand it correctly, this alone will not solve the descheduler problem; this is just one piece of the puzzle. Correct?
Thank you for the feedback @RobertKrawitz. I was hoping to understand from you whether this design would solve the descheduler problem. What are the gaps that you see?
AFAIU from my discussions with @stu-gott, the agreement was:
- Add the
descheduler.alpha.kubernetes.io/request-evict-only
annotation to allvirt-launcher
pods.- Add the
descheduler.alpha.kubernetes.io/eviction-in-progress
annotation tovirt-launcher
pods which received the eviction request and will be migrated from the node because of it.
The descheduler itself needs to respect these new annotations. It isn't clear to me from the description whether it does.
If I understand it correctly, this alone will not solve the descheduler problem; this is just one piece of the puzzle. Correct?
Thank you for the feedback @RobertKrawitz. I was hoping to understand from you whether this design would solve the descheduler problem. What are the gaps that you see? AFAIU from my discussions with @stu-gott, the agreement was:
- Add the
descheduler.alpha.kubernetes.io/request-evict-only
annotation to allvirt-launcher
pods.- Add the
descheduler.alpha.kubernetes.io/eviction-in-progress
annotation tovirt-launcher
pods which received the eviction request and will be migrated from the node because of it.The descheduler itself needs to respect these new annotations. It isn't clear to me from the description whether it does.
Yes, the descheduler needs to respect the new annotations. It is stated under "Non Goals".
If I understand it correctly, this alone will not solve the descheduler problem; this is just one piece of the puzzle. Correct?
Thank you for the feedback @RobertKrawitz. I was hoping to understand from you whether this design would solve the descheduler problem. What are the gaps that you see? AFAIU from my discussions with @stu-gott, the agreement was:
- Add the
descheduler.alpha.kubernetes.io/request-evict-only
annotation to allvirt-launcher
pods.- Add the
descheduler.alpha.kubernetes.io/eviction-in-progress
annotation tovirt-launcher
pods which received the eviction request and will be migrated from the node because of it.The descheduler itself needs to respect these new annotations. It isn't clear to me from the description whether it does.
Yes, the descheduler needs to respect the new annotations. It is stated under "Non Goals".
Exactly -- without that, the solution is not complete.
Change: Following @EdDev's advice - moved the way KubeVirt currently handles eviction requests to a separate document in order to simplify this document.
Descheduler proposal: https://github.com/kubernetes-sigs/descheduler/pull/1354
@EdDev @dankenigsberg @fabiand @ingvagabund @RobertKrawitz, are any other changes required for this design proposal? If not would you lgtm so we can get it merged?
@acardace what would you as an approver say? Is this proposal aligned with what we expected on the descheduelr side? And does @ingvagabund bless this design here?
/lgtm
@fabiand looks thorough to me.
@acardace great - and are you in sync with @ingvagabund ?
@acardace great - and are you in sync with @ingvagabund ?
Can you elaborate? I'm just doing a gentle ping to all parties involved in the review to move this on, it's been a couple of weeks without progress.
I'm just trying to say that the approving approver should ensure that the design is working for us, but like in this case to also ensure that everything we depend on is also good.
Combination of 429 - VM will be migrated
(code and text/message) and the annotations is the crucial part for the descheduler.
LGTM
/lgtm
@RobertKrawitz: changing LGTM is restricted to collaborators
/approve
This proposal matches expectations of what KubeVirt should do. The descheduler team has signed off on our approach.
@fabiand it appears you're the only approver for this repo participating in this conversation.
/approve
According to Stu's comment
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: fabiand, stu-gott
The full list of commands accepted by this bot can be found here.
The pull request process is described here
What this PR does / why we need it: Add a design proposal to support running KubeVirt in a cluster that also has a descheduler.
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 #Special notes for your reviewer: PR https://github.com/kubevirt/kubevirt/pull/11286 describes the current way KubeVirt handles eviction requests.
Descheduler proposal: https://github.com/kubernetes-sigs/descheduler/pull/1354
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR. Approvers are expected to review this list.
Release note: