1.7. Known issues

When powering on a virtual machine on vSphere with user-provisioned infrastructure, the process of scaling up a node might not work as expected. A known issue in the hypervisor configuration causes machines to be created within the hypervisor but not powered on. If a node appears to be stuck in the Provisioning state after scaling up a machine set, you can investigate the status of the virtual machine in the vSphere instance itself. Use the VMware commands govc tasks and govc events to determine the status of the virtual machine. Check for a similar error message to the following:

[Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize(8192). ]

You can attempt to resolve the issue with the steps in this VMware KBase article. For more information, see the Red Hat Knowledgebase solution [UPI vSphere] Node scale-up doesn’t work as expected. (BZ#1918383)

If you scale up with a RHEL worker while running a cluster on RHOSP that uses user-provisioned infrastructure, all routes are inaccessible if the Ingress port VIP is on the RHEL worker. As a workaround, you must reschedule the router pod to an RHCOS node and make the Ingress VIP migrate to the RHCOS node. To do this, add the node.openshift.io/os_id: rhcos label to the Ingress Controller before upgrade:

$ oc -n openshift-ingress-operator edit ingresscontroller/default -o yaml
spec:
  nodePlacement:
    nodeSelector:
      matchLabels:
        kubernetes.io/os: linux
        node-role.kubernetes.io/worker: ""
        node.openshift.io/os_id: rhcos

(BZ#1848945)

An issue has been found for the s390x and ppc64le architectures that renders nodes unavailable for workloads after a forced reboot or power down. Do not force reboot or power down nodes.

If a forced reboot or power down is unavoidable and a node that comes back up is unavailable for workloads:

If an AWS account is configured to use AWS Organizations service control policies (SCPs) that use a global condition to deny all actions or require a specific permission, OpenShift Container Platform AWS installations fail, even if the provided credentials have the required permissions for installation.

A workaround for this issue is introduced in OpenShift Container Platform 4.5.8. (BZ#1829101)

In OpenShift Container Platform 4.1, anonymous users could access discovery endpoints. Later releases revoked this access to reduce the possible attack surface for security exploits because some discovery endpoints are forwarded to aggregated API servers. However, unauthenticated access is preserved in upgraded clusters so that existing use cases are not broken.

If you are a cluster administrator for a cluster that has been upgraded from OpenShift Container Platform 4.1 to 4.5, you can either revoke or continue to allow unauthenticated access. It is recommended to revoke unauthenticated access unless there is a specific need for it. If you do continue to allow unauthenticated access, be aware of the increased risks.

Use the following script to revoke unauthenticated access to discovery endpoints:

## Snippet to remove unauthenticated group from all the cluster role bindings
$ for clusterrolebinding in cluster-status-binding discovery system:basic-user system:discovery system:openshift:discovery ;
do
### Find the index of unauthenticated group in list of subjects
index=$(oc get clusterrolebinding ${clusterrolebinding} -o json | jq 'select(.subjects!=null) | .subjects | map(.name=="system:unauthenticated") | index(true)');
### Remove the element at index from subjects array
oc patch clusterrolebinding ${clusterrolebinding} --type=json --patch "[{'op': 'remove','path': '/subjects/$index'}]";
done

This script removes unauthenticated subjects from the following cluster role bindings:

(BZ#1821771)