+++ This bug was initially created as a clone of Bug #1810841 +++

Description of problem:


This is our official documentation for placing infra workloads on infra nodes: 
https://docs.openshift.com/container-platform/4.3/machine_management/creating-infrastructure-machinesets.html#infrastructure-moving-monitoring_creating-infrastructure-machinesets

Its instructions won't work in many cases, because they don't assume that the cluster's default scheduler scheduler/cluster can be set with anything else other than the default worker.

For example: 

spec:
  defaultNodeSelector: node-role.kubernetes.io/application=

Assuming it's unset is unrealistic. This is the first thing a customer who wishes to avoid apps starting on infra nodes will set after they build their infra nodes.

Every infra component then needs to override this setting - by adding  (openshift.io/node-selector: "") to its namespace. 

Most infra components already have this automatically done by the operator (openshift-monitoring, openshift-ingress-opertor,  openshift-image-registry ). Two do not - openshift-ingress and openshift-logging.

Can we have this done by the Operator itself, i.e, adding a blank override? 

Or can this just be done by a documentation bug itself? By adding the following workaround.
 
For the ingress router section, please add a blank override (openshift.io/node-selector: "") to the openshift-ingress namespace to look like this:
$ oc get ns/openshift-ingress -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/node-selector: ""

For the logging section, please add a blank override (openshift.io/node-selector: "") to the openshift-logging namespace to look like this:
$ oc get ns openshift-logging -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/node-selector: ""

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

OCP 4.3

How reproducible:


Steps to Reproduce:
1. Scheduling Any components other than app workloads to infra nodes.
2. The default instructions in the documentation does not work in all scenarios.


Actual results:

Pods to be scheduled as per the requirement.

Expected results:

Corresponding Operator should be able to handle the task of having a label at the namespacelevel


Additional info:

Please suggest if just a documentation change is enough or if operator level change is needed as well.