Installer: UPI for vSphere: The argument "region" is required, but was not set.

[saintdle]

I get the error;

The argument "region" is required, but was not set.

There seems to be a requirement for AWS Account and Region in the current master to deploy to vSphere, which is not needed at all if this is a full on prem deployment. I tried unpicking but to no avail. Folder structure and configuration looks completely different to older revisions as descibed in these two links;

https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-openshift-runbook-runbook-install-intro#vcs-openshift-runbook-install-related

https://www.openshift.com/blog/deploying-a-user-provisioned-infrastructure-environment-for-openshift-4-1-on-vsphere

Also had to edit in terraform.tfvars from errors throw in terraform pan

bootstrap_ip
control_plane_ips
compute_plane_ips

To;

bootstrap_ip_address
control_plane_ip_addresses
compute_plane_ip_addresses

and finally add in the line

bootstrap_ignition_path = "xxxxx"

[abhinavdahiya]

The example in the master uses route53 for DNS and therefore it is required. If you don't intend to use route53, feel free to take those example and modify it to remove them with whatever you have on-prem.

We do not intend to make the example any more configurable.

Secondly the issue does not follow the template included that allows us to help reproduce and triage the bug, and so I would request you update the issue to help us triage better. https://github.com/openshift/installer/blob/master/.github/ISSUE_TEMPLATE.md

[crissonpl]

@abhinavdahiya I don't understand your comments. what @saintdle is pointing are the basic errors - did anyone actually tried to deploy OCP on VMWare with the new version? it doesn't work.

@saintdle did you figure out how to work around the issue with the region?

[saintdle]

@abhinavdahiya I don't understand your comments. what @saintdle is pointing are the basic errors - did anyone actually tried to deploy OCP on VMWare with the new version? it doesn't work.

@saintdle did you figure out how to work around the issue with the region?

Correct, I don't think the response was great, many on=prem vmware environments do not use AWS for DNS, so having this "example" doesn't feel relevant.

I couldn't unpick the files to stop this from happening, so I reverted to branch release 4.3, removed the DNS module references in the main.tf file.

This worked fine.

[pavanandhukuri]

I am facing the same problem when trying to install 4.5 version of the cluster. The documentation also does not seem to reflect the necessary changes.

[LorbusChris]

dupe of https://github.com/openshift/installer/issues/3674 ?

edit: for the region issue, see https://github.com/openshift/installer/issues/3674#issuecomment-663537934 specifically

[saintdle]

dupe of #3674 ?

edit: for the region issue, see #3674 (comment) specifically

That's fine setting those variables, if you are using Route53 for DNS.

However you have to question who is using Route53 for DNS when deploying to on-prem vSphere, you'd expect them to have some sort of on-prem solution. So either the files need to be updated to be more realistic examples, or just remove the DNS configuration.

As these are examples and you can make edits to suit your environment, I also understand that point. I just feel that the product inaccessible for those who are learning or on their first steps using these examples. It took em a while whilst learning OCP to understand how to get around this.

Admitedly 4.5.x code is miles ahead thanks to IPI support for vSphere. But I can still see the need for people to deploy 4.4.x and below.

[RobbieJVMW]

Confusion around how to setup DNS on on-prem or even air-gapped environments for OCP is a common issue. Anything that implies a connection to a cloud service should document an alternative option; many vSphere deployments are dark sites without direct internet connectivity and they certainly wouldn't consider Route53 for DNS or other datacenter critical services.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale