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:
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