Uploaded image for project: 'OpenShift Hive'
  1. OpenShift Hive
  2. HIVE-2289

Deploy OpenShift to a shared VPC in OSD

XMLWordPrintable

    • Deploy OpenShift to a shared VPC in OSD
    • False
    • None
    • False
    • Not Selected
    • To Do
    • OCPSTRAT-260 - Extend Installer's capabilities while deploying OCP to a shared VPC in GCP
    • OCPSTRAT-260Extend Installer's capabilities while deploying OCP to a shared VPC in GCP

      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

      • Enable OpenShift to be deployed to a shared VPC in GCP, while also supporting BYO hosted zones.
      • 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.
      •  

      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 can use either UPI or IPI to deploy into a shared VPC in GCP.

      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.
      • ...

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      Open questions::

      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>

              Unassigned Unassigned
              julim Ju Lim
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: