Epic Goal

• Add Gateway API via Istio Gateway implementation as Tech Preview in 4.x

Problem: ** As an administrator, I would like to securely expose cluster resources to remote clients and services while providing a self-service experience to application developers. 

Tech Preview:  A feature is implemented as Tech Preview so that developers can issue an update to the Dev Preview MVP and:

• can still change APIs that are clearly indicated as tech preview, without following a deprecating or backwards compatibility process.
• are not required to fix bugs customers uncover in your TP feature.
• do not have to provide an upgrade path from a customer using your TP feature to the GA version of your feature.
• TBD - must still support upgrading the cluster and your component, but it’s ok if the TP feature doesn’t work after the upgrade.
• still need to provide docs (which should make it clear the feature is tech preview)
• still need to provide education to CEE about the feature (tech enablement)
• must also follow Red Hat's support policy for tech preview
  From https://github.com/openshift/enhancements/blob/master/guidelines/techpreview.md

Why is this important?

• Reduces the burden on Red Hat developers to maintain IngressController and Route custom resources
• Brings OpenShift ingress configuration more in line with standard Kubernetes APIs
• Demonstrates Red Hat’s leadership in the Kubernetes community.

Scenarios

1. ...

Acceptance Criteria (draft)

• Gateway API and Istio Gateway are in an acceptable standing for Tech Preview
  • NE-1116
  • NE-1273
  • NE-1000
  • stretch NE-1190
  • stretch NE-1297
  • stretch NE-1098
  • stretch NE-996
• Now that we've decided on single control plane (shared between OSSM and Network Edge functionality), complete the feature in collaboration with OSSM
  • NE-1095
  • NE-1139
• Decide on whether we can make an existing OSSM control plane work when the GWAPI feature is enabled on the cluster
  • NE-1178 (subtask)
• Decide if the cluster admin can/should configure SMCP, what options are exposed, and API for configuration
  • NE-1290
  • stretch NE-1291
• Document limitations and collect information to plan future work needed to accommodate HyperShift architecture - in OSSM and elsewhere
  • stretch NE-1288
• Initial security model
  • NE-1112
• Enhancement Proposals, Migration details, Tech Enablement, and other input for QA and Docs as needed
  • NE-1110
  • NE-1261
  • NE-1336
  • OSDOCS-5040
  • stretch NE-1106
  • stretch NE-999
• Web console
  • stretch NE-1109
• Must-gather updates
  • stretch NE-1277
• CI, E2E tests on GA OSSM
  • NE-1272
  • NE-1334
• Metrics/Telemetry as needed
  • NE-1335
• Installation, Upgrade details (keep OSSM and c-i-o in sync)
  • NE-1326
• [stretch] oc updates
  • NE-1102

Dependencies (internal and external)

1. OSSM release schedule aligned with OpenShift's cadence, or workaround designed
2. ...tbd

Previous Work (Optional):

1. https://issues.redhat.com/browse/NE-993
2. https://issues.redhat.com/browse/NE-1036

Open questions::

1. …

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>