Placeholder, the gist is: every time AWS releases a new region, we need to touch code in various subsystems and components of OpenShift. This is not scalable. We should make it so that we are agnostic to region support changes in AWS at compile time.

We addressed some of this in the past, e.g. Image Registry.  We need to identify all the end-to-end places that require code changes and releases to allow new clusters in these new regions. 

Outcome Overview

Once all Features and/or Initiatives in this Outcome are complete, what tangible, incremental, and (ideally) measurable movement will be made toward the company's Strategic Goal(s)?

OpenShift will support new AWS regions without code changes or new releases. Customers can use new regions as soon as AWS makes them available, without waiting for OpenShift releases. This removes the current ~1+ month enablement cycle and aligns OpenShift with AWS’s regional expansion.

Current Enablement Checklist for Self-Managed OpenShift (based on OCPSTRAT-2500, OCPSTRAT-653, OCPSTRAT-1221):

Current Enablement Checklist for Managed OpenShift (based on ARO-19822, ARO-20433, OCPSTRAT-1221, RFE-4770, HCMSTRAT-19):

Success Criteria

What is the success criteria for this strategic outcome?  Avoid listing Features or Initiatives and instead describe "what must be true" for the outcome to be considered delivered.

Currently, this takes us over a month to enable new regions.  We want customer to be able to try new regions without consuming new code releases.

• Customers can deploy OpenShift in new AWS regions without consuming new OpenShift releases.
  Enablement time for new regions drops from over one month to near zero (no code changes or releases required).
• All subsystems that currently require manual changes (RHCOS, CORS/Installer, OCPCloud, Storage, Hive, managed services) are region-agnostic at runtime.

Expected Results (what, how, when)

What incremental impact do you expect to create toward the company's Strategic Goals by delivering this outcome?  (possible examples:  unblocking sales, shifts in product metrics, etc. {}{} provide links to metrics that will be used post-completion for review & pivot decisions). {}For each expected result, list what you will measure and +when you will measure it (ex. provide links to existing information or metrics that will be used post-completion for review and specify when you will review the measurement such as 60 days after the work is complete)

• What: Faster time-to-market for new AWS regions; reduced engineering effort per region.
• How: Make region support data-driven and configurable instead of hardcoded; remove region-specific code paths.
• When: Measure time from AWS region GA to OpenShift support; target <1 week (vs. current >1 month).

Post Completion Review – Actual Results

After completing the work (as determined by the "when" in Expected Results above), list the actual results observed / measured during Post Completion review(s).