Bug 1931803

Summary:	VM can be left without handler
Product:	Container Native Virtualization (CNV)	Reporter:	Fabian Deutsch <fdeutsch>
Component:	Virtualization	Assignee:	sgott
Status:	CLOSED DUPLICATE	QA Contact:	Israel Pinto <ipinto>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	2.6.0	CC:	cnv-qe-bugs, kbidarka
Target Milestone:	---
Target Release:	4.8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-02-24 13:26:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Fabian Deutsch 2021-02-23 09:43:26 UTC

Description of problem:
If the label of the handler daemonset is changed, then pods of this daemonset might be removed from certain nodes, but at the same time, a VM on such a node will stay.
The bug is that a VM is left without a handler which it needs for working correctly.

Version-Release number of selected component (if applicable):
2.6.0

How reproducible:
Always

Steps to Reproduce:
1. Install CNV
2. Set handler nodeSelector
3. Schedule VMs
4. Change nodeSelector in a way to remove the handler from at least one node which is running a VM

Actual results:
VM will continue to run while handler is gone

Expected results:
VMs will run with a companion handler

In the scenario above this could mean that the handler will stay, or that the VM will leave - or we simply react with alerts

Additional info:

Comment 1 Fabian Deutsch 2021-02-23 10:06:18 UTC

The topic also got discussed in https://issues.redhat.com/browse/CNV-8159?focusedCommentId=15684400&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15684400

Comment 2 sgott 2021-02-24 13:16:22 UTC

This is one of those situations that it's hard to avoid, because KubeVirt cannot block changes to labels/taints of nodes--so the most reasonable course of action is to fire an alert if this situation arises.

Comment 3 Kedar Bidarkar 2021-02-24 13:26:29 UTC


*** This bug has been marked as a duplicate of bug 1917380 ***

Comment 4 sgott 2021-02-24 13:27:34 UTC

Because the BZ linked in comment 3 was solved by adding an alert, this BZ appears to be a duplicate of that. Please re-open if you think this is in error.