Bug 1773661

Summary:	catalog source pods are scheduled onto windows nodes
Product:	OpenShift Container Platform	Reporter:	Daniel Sover <dsover>
Component:	OLM	Assignee:	Daniel Sover <dsover>
OLM sub component:	OLM	QA Contact:	Salvatore Colangelo <scolange>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	high
Priority:	unspecified
Version:	4.3.0
Target Milestone:	---
Target Release:	4.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1774752 (view as bug list)		Environment:
Last Closed:	2020-01-23 11:13:05 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:
Bug Depends On:
Bug Blocks:	1774752, 1775180

Description Daniel Sover 2019-11-18 16:39:26 UTC

Description of problem:
Customer raised a github issue noting that the operatorhubio pod was scheduled onto a windows node in a split linux/windows cluster. See https://github.com/operator-framework/operator-lifecycle-manager/issues/1119 for full description.

Since catalog sources are compiled for linux the pod fails to start on the windows VM. As we see more mixed clusters this bug will become more common.  


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


How reproducible:
Always

Steps to Reproduce:
1. Create catalog source pods in a mixed OS cluster
2. Since there is no node selector for catalog source pods, some will eventually end up on windows VMs and fail to start. 
3.

Actual results:
Pod ends up on windows VM and fails to start

Expected results:
Pod is always scheduled to a linux VM like other OLM-related pods

Additional info:

Comment 5 errata-xmlrpc 2020-01-23 11:13:05 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0062