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

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

XMLWordPrintable

    • Support deploying OCP in “GCP Service Project” while networks are defined in “GCP Host Project”
    • False
    • False
    • Done
    • OCPSTRAT-232 - Enable OpenShift IPI Installer to deploy OCP to a shared VPC in GCP - GA
    • Impediment
    • OCPSTRAT-232Enable OpenShift IPI Installer to deploy OCP to a shared VPC in GCP - GA
    • 100
    • 100% 100%

      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>

        There are no Sub-Tasks for this issue.

            rh-ee-bbarbach Brent Barbachem
            mak.redhat.com Marcos Entenza Garcia
            Jianli Wei Jianli Wei
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: