Version:
4.8

Platform:
Azure, vmware, doesn't really matter

Please specify:

• UPI

What happened?
Strategic customer reported an inability to provision OpenShift 4.7 in their Azure environment. They said the bootstrap host never is able to pull down its ignition configuration. We noticed some issues with the network, but because we were unable to access the grub menu on Azure (not fast enough), we were never able to break into the system to validate network access.

It turns out the customer's Azure engineering team never configured egress or ingress to the VNET the cluster was installing to. Because of the challenges accessing a CoreOS machine in Azure, and the customer's strict security requirements precluding us from installing additional VMs in that same VNET to do our own troubleshooting, we wasted a lot of time chasing a nonexistent problem.

What did you expect to happen?
I'd like to propose that we build some sort of pre-flight check in the bootstrap that outputs to the system console. It might look something like this:

1. I have an IP Address, a gateway, and I'm able to contact the gateway
2. I have a DNS server configured, and I'm able to contact the DNS server
3. I have a ignition host configured, and I can curl/ping the ignition host

The intention is to make it easier for customers and support engineers to determine quickly by looking at the boot exactly what the situation is without having to break into the box.