Exploring OpenShift 4.X Bootstrap Machine

In the search of a solid surface to create a set of DevOps practices for Openshift 4.X deployment engagements, my personal journey had started by looking to the Bootstrap node as a good spot to bring agility and effectiveness to my job as an implementation consultant.

Yup... I know! The official documentation says that you should treat Bootstrap as a weird thing you are supposed to touch with a stick just to double check if it's alive or not.

However, look at the alternatives:

• Intuitively, deploying an ocp4-helpernode machine seems like a good idea to validate Pre-Reqs, but isn't it Helper-Node doing something quite similar to a Bootstrap machine?

(ERRATA [12/18/2021] Actually, they are quite different: Helper-Node is not just a Pre-Reqs validation tools, it allows to deploy an OCP cluster by providing the needed settings to allow node discovery. On the other hand, Bootstrap's goal is to create an ETCD cluster that allow Masters to work)

• Trying to troubleshoot by treating Bootstrap as a black box is not troubleshooting. It's more like guessing. The reason being that if you are missing a Pre-Req, you may not have a proper evidence of what is causing the issue.

In this context, instead of running openshift-install and crossing fingers. Implementation consultants can proactively follow the scripts and find the specific point at which the deployment is stuck.

(ERRATA [12/18/2021] In essence, Bootstrap logs will tell you if you have access to Quay images, which can be local (disconnected installation), from the internet directly or by using a Proxy. Beside that, you can also get from the logs information about connecting to the API Load-Balancer and the Masters)