Uploaded image for project: 'OpenShift Installer'
  1. OpenShift Installer
  2. CORS-1774

Enable OpenShift IPI Installer to deploy OCP to a shared VPC in GCP [Tech Preview]

XMLWordPrintable

    • Support deploying OCP in “GCP Service Project” while networks are defined in “GCP Host Project”
    • False
    • False
    • Done
    • Impediment
    • 0% To Do, 0% In Progress, 100% Done

      Epic Goal

      • Enable OpenShift IPI Installer to deploy OCP to a shared VPC in GCP.
      • The host project is where the VPC and subnets are defined. Those networks are shared to one or more service projects.
      • Objects created by the installer are created in the service project where possible. Firewall rules may be the only exception.
      • Documentation outlines the needed minimal IAM for both the host and service project.

      Why is this important?

      • Shared VPC's are a feature of GCP to enable granular separation of duties for organizations that centrally manage networking but delegate other functions and separation of billing. This is used more often in larger organizations where separate teams manage subsets of the cloud infrastructure. Enterprises that use this model would also like to create IPI clusters so that they can leverage the features of IPI. Currently organizations that use Shared VPC's must use UPI and implement the features of IPI themselves. This is repetative engineering of little value to the customer and an increased risk of drift from upstream IPI over time. As new features are built into IPI, organizations must become aware of those changes and implement them themselves instead of getting them "for free" during upgrades.

      Scenarios

      1. Deploy cluster(s) into service project(s) on network(s) shared from a host project.

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      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>

              jstuever@redhat.com Jeremiah Stuever
              mak.redhat.com Marcos Entenza Garcia
              Jianli Wei Jianli Wei
              Votes:
              0 Vote for this issue
              Watchers:
              23 Start watching this issue

                Created:
                Updated:
                Resolved: