Feature Overview

(Part 1)

An OCP cluster must have a component that serves as single source of truth for identification of clusterName and baseDomain. Currently, the installers uses the clusterName and baseDomain to generate various artifacts during the installation but there is no ownership for this information for day-2 identification of clusterName and baseDomain attributes.
 
This feature is to extend Infrastructure CRD to have two new attributes:

• .spec.clusterName
• .spec.baseDomain{}

spec:

  clusterName: ocp

  baseDomain: example.com

The actual state of these attributes should also be reported in the .status section.

This will enable cluster operators to follow this attribute as the source of truth for this information without having to run host-level privileged functions trying to derive the information or without having dependencies on other operators.

This will provide the construct for specific platform providers (e.g. baremetal, external, none) to choose when and if, to support the change of clusterName and baseDomain (Part 2 Option A) or the addition of aliases for names and domains to the cluster (Part 2 Option B)

(Part 2 Option A)  

Enable the ability for a cluster-admin to update the .spec.clusterName and .spec.baseDomain

spec:

  clusterName: foo

  baseDomain: acme.com

• If the platform provider in use supports updating these attributes as Day-2 operation:
  • Cluster operators with dependencies on these attributes should watch the .status of the Infrastructure CR for updates/changes and respond accordingly by:

• • • generating external-facing certs for the new domain
    • reconfiguring any of its internal dependencies
    • start operating with the new name and domain.

Update Sep 2023: Option B is no longer a consideration (Part 2 Option B) 

Enable the ability for a cluster-admin to add additional (aliases) clusterName and baseDomain  as first-citizen for the cluster.

spec:

  clusterName: ocp

  baseDomain: example.com

  additionalNames:

  clusterName: foo{}-

    baseDomain: acme.com

  clusterName: bar-

    baseDomain: example.org

• If the platform provider in use supports updating these attributes as Day-2 operation:
  • Cluster operators with dependencies on these attributes should watch the .status of the Infrastructure CR for updates/changes/additions/removals and respond accordingly by:

• • • generating or removing external-facing certs for the additional names and baseDomain
    • reconfiguring any of its internal dependencies
    • start operating with the new name and domain.

Use Cases

Support OCP platform reconfigurations for the following use cases:

1. Recovery of OCP clusters on a disaster recovery scenario where the cluster is restored from backups to a DR location where it is not possible to operate using the same identity from the main locations
2. Ability to pre-provision clusters on Cloud or virtualization environments and keep them as "standby clusters" until it is required to go immediately in use at which point it is reconfigured as a day-2 operation completely eliminating the need for any type of installation of platform and other workload.
3. Ability to create appliances with OCP which are then reconfigured as day-2 operation when arriving to their destination
4. Ability to relocate cluster across domains or name schemes
5. Ability for Telecommunication providers and large scale industrial deployments to follow a process where OCP is pre-installed from factory or on a staging facilities including all their specialized software stack on top of OCP, and have the ability to ship those pre-installed clusters (SNO, compact, multi-node) to the final locations and have them running with the site specific information by a day-2 reconfiguration.

Requirements (aka. Acceptance Criteria):

• Platform provides a single source of truth for the clusterName and baseDomain attributes for the cluster.
• Cluster-Admin can change or add clusterName and baseDomain (when supported by the platform type)
• Define CI-test to validate this feature 

Out of Scope

• The integration with a platform type is out of scope for this Feature (that will be worked separately)

Customer Considerations

This feature is critical for the delivery of OCP reconfiguration required for Telco Edge deployments and for the support of a disaster recovery procedure required by some regulated industries.

Interoperability Considerations

When upgrading from a previous OCP version to one supporting this API, the values should be auto-populated.