Hive Impact

We would theoretically get a lot of support for free via install-config.

However...

ClusterDeployment.Spec.Platform.VSphere is a reflection of the install-config counterpart. Today this does not affect the install-config provided via the ClusterDeployment for day 0. It is only used to feed MachinePools, where it informs the (single) failureDomain for which the generated MachineSets are to be created. With this feature, folks will want the flexibility to put their day 2 MachineSets into whatever failureDomain(s) they choose, not necessarily locked to the same ones the default worker pool is using. So pulling that information from either the install-config (which may not necessarily even exist day 2!) or the CD won't work.

The situation with ClusterPools is kind of a mess. We accept an install-config template XOR we generate an install-config piecemeal from the ClusterPool.Spec.Platform.VSphere! And btw, that schema sub-object is the same one ClusterDeployment uses.

Next we have the vsphere-specific hiveutil create-cluster CLI. It already has a horrible mess of flags, including (singular) ones for datacenter, folder, etc – all the things that are now blown out into lists for multi-AZ support.

And the ClusterPool code shares its builder with that CLI.

Then of course there's the whole thing with MachinePools+ClusterPools being busted in the first place.

In summary...

Day 0

install-config, as today. However, we should document (where??) that (the relevant parts of???) cd.spec.platform.vsphere won't do anything.

MachinePools

We should look into whether we can just import the install-config platform object into the MachinePool schema... but ISTR that's not possible because the install-config thingy isn't a runtime.Object or something.

In which case our only recourse is to clone (the relevant parts of) it. Ugh.

ClusterPools

We could update the spec.platform.vsphere. But remember, that's shared with CD. Which will make it feel even weirder that that section is ignored for CD.

I suppose we could fork ClusterPool.spec.platform(.vsphere?) so we can maintain it independently of CD? Again ugh.

hiveutil

I'm inclined to say we open a card for this, put it on the backlog, and then never address it. If you want to do zonal stuff via hiveutil, use it to generate the install-config and edit it by hand.

---

OCP/Telco Definition of Done
Epic Template descriptions and documentation.

<--- Cut-n-Paste the entire contents of this description into your new Epic --->

Epic Goal

Install OpenShift on vSphere using Hive in multiple regions and zones.

Scenarios

1. As an Infrastructure Administrator, I want to deploy OpenShift on vSphere distributing the control plane and compute nodes across multiple regions and zones, forming different failure domains.
2. As an Infrastructure Administrator, I want to configure an existing OpenShift cluster to distribute the nodes across regions and zones, forming different failure domains.

Acceptance Criteria

• Ensure OpenShift on vSphere can successfully be deployed with ODF across multiple zones via Hive
• Ensure zonal configuration in vSphere using Hive is documented and tested
• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.

Dependencies (internal and external)

1. ...

Previous Work (Optional):

Zonal support for vSphere was GAed in OpenShift 4.13 (see OCPSTRAT-153)

This implementation would follow the same idea that has been done for vSphere IPI and UPI. The following are the main PRs for vSphere:

https://github.com/openshift/enhancements/blob/master/enhancements/installer/vsphere-ipi-zonal.md 

 

Existing vSphere documentation

https://docs.openshift.com/container-platform/4.13/installing/installing_vsphere/installing-vsphere-installer-provisioned-customizations.html#configuring-vsphere-regions-zones_installing-vsphere-installer-provisioned-customizations

https://docs.openshift.com/container-platform/4.13/post_installation_configuration/post-install-vsphere-zones-regions-configuration.html

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>