-
Epic
-
Resolution: Unresolved
-
Critical
-
None
-
None
-
Add GA Support for Gateway API via Istio
-
BU Product Work
-
False
-
None
-
False
-
Green
-
In Progress
-
OCPSTRAT-134 - Gateway API using Istio for Cluster Ingress - GA
-
-
0% To Do, 8% In Progress, 92% Done
-
XL
-
0
-
0
Epic Goal
- Add Gateway API via Istio Gateway implementation as GA in future release
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.
GA: A feature is implemented as GA so that developers can issue an update to the Tech Preview MVP and:
- can no longer change APIs without following a deprecating or backwards compatibility process.
- are required to fix bugs customers uncover
- must support upgrading the cluster and your component
- provide docs
- provide education to CEE about the feature
- must also follow Red Hat's support policy for GA
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
- ...
Acceptance Criteria
- Gateway API and Istio Gateway are in an acceptable standing for GA
- Istio Gateway installation without sidecars enabled
- Decision completed on whether a new operator is required, especially for upgrade and status reports
- Decision completed on whether Ingress->Gateway (or Route->Gateway) translation is needed
- Enhancement Proposals, Migration details, Tech Enablement, and other input for QA and Docs as needed
- API server integration, Installation, CI, E2E tests, Upgrade details, Telemetry as needed
- TBD
Dependencies (internal and external)
- OSSM release schedule aligned with OpenShift's cadence, or workaround designed
- ...tbd
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>
[NE-1117] [GWAPI-GA] Add GA Support for Gateway API via Istio
pme bot
made changes -
| WSJF | New: 0 | |
| WSJF | New: 0 |
| Size | New: XL [ 36358 ] |
| Priority | Original: Undefined [ 10300 ] | New: Critical [ 2 ] |
pme bot
made changes -
| Epic Status | Original: To Do [ 10450 ] | New: In Progress [ 10451 ] |
OpenShift Jira Links Copy Bot
made changes -
| Remote Link |
New:
This issue links to "openshift/enhancements#1756: |
Michael Fisher
made changes -
| Summary | Original: Add GA Support for Gateway API via Istio | New: [GWAPI-GA] Add GA Support for Gateway API via Istio |
| QA Contact | New: Ishmam Amin [ JIRAUSER186762 ] |
Michael Fisher
made changes -
| Rank | New: Ranked higher |
Michael Fisher
made changes -
| Rank | New: Ranked lower |
Michael Fisher
made changes -
| Rank | New: Ranked higher |
Michael Fisher
made changes -
| Labels | Original: gateway-api network-edge | New: 4.19-candidate gateway-api network-edge |
Michael Fisher
made changes -
| Status | Original: New [ 10016 ] | New: In Progress [ 10018 ] |
Michael Fisher
made changes -
| Rank | New: Ranked higher |
OpenShift Jira Links Copy Bot
made changes -
| Remote Link |
New:
This issue links to "openshift/cluster-ingress-operator#933: |
Deepthi Dharwar
made changes -
Deepthi Dharwar
made changes -
OpenShift Jira Automation Bot
made changes -
| Work Type | New: BU Product Work [ 40155 ] |
| Priority | Original: Critical [ 2 ] | New: Undefined [ 10300 ] |
| Description |
Original:
h1. Epic Goal
* Add Gateway API via Istio Gateway implementation as GA in future release *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. *GA:* A feature is implemented as GA so that developers can issue an update to the Tech Preview MVP and: * can no longer change APIs without following a deprecating or backwards compatibility process. * are required to fix bugs customers uncover * must support upgrading the cluster and your component * provide docs * provide education to CEE about the feature * must also follow Red Hat's support policy for GA h2. 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. h2. Scenarios # ... h2. Acceptance Criteria * Gateway API and Istio Gateway are in an acceptable standing for GA * Istio Gateway installation without sidecars enabled * TBD * Enhancement Proposals, Migration details, Tech Enablement, and other input for QA and Docs * API server integration, Installation, CI, E2E tests, Upgrade details, Telemetry Dependencies (internal and external) # OSSM release schedule aligned with OpenShift's cadence, or workaround designed # ...tbd h2. Previous Work (Optional): # https://issues.redhat.com/browse/NE-993 # https://issues.redhat.com/browse/NE-1036  # h2. Open questions:: # … h2. 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> |
New:
h1. Epic Goal
* Add Gateway API via Istio Gateway implementation as GA in future release *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. *GA:* A feature is implemented as GA so that developers can issue an update to the Tech Preview MVP and: * can no longer change APIs without following a deprecating or backwards compatibility process. * are required to fix bugs customers uncover * must support upgrading the cluster and your component * provide docs * provide education to CEE about the feature * must also follow Red Hat's support policy for GA h2. 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. h2. Scenarios # ... h2. Acceptance Criteria * Gateway API and Istio Gateway are in an acceptable standing for GA * Istio Gateway installation without sidecars enabled * Decision completed on whether a new operator is required, especially for upgrade and status reports * Decision completed on whether Ingress->Gateway (or Route->Gateway) translation is needed * Enhancement Proposals, Migration details, Tech Enablement, and other input for QA and Docs as needed * API server integration, Installation, CI, E2E tests, Upgrade details, Telemetry as needed * TBD Dependencies (internal and external) # OSSM release schedule aligned with OpenShift's cadence, or workaround designed # ...tbd h2. Previous Work (Optional): # https://issues.redhat.com/browse/NE-993 # https://issues.redhat.com/browse/NE-1036  # h2. Open questions:: # … h2. 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> |
| Link | New: This issue is documented by OSDOCS-5036 [ OSDOCS-5036 ] |
| Labels | Original: network-edge | New: gateway-api network-edge |
| Target Version | Original: openshift-4.13 [ 12393941 ] |
| Labels | Original: gateway-api network-edge | New: network-edge |
| Description |
Original:
h1. Epic Goal
* Add Gateway API via Istio Gateway implementation as Tech Preview in 4.13 (proposed) *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. * 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 * must also follow Red Hat's support policy for tech preview From [https://github.com/openshift/enhancements/blob/master/guidelines/techpreview.md] h2. 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. h2. Scenarios # ... h2. Acceptance Criteria * Gateway API and Istio Gateway are in an acceptable standing for Tech Preview * Istio Gateway installation without sidecars enabled * Decision completed on whether we use a single control plane (shared between OSSM and Network Edge functionality), or multiple control planes (separate CPs for OSSM and Network Edge functionality) * Decision completed on changes needed to accommodate HyperShift architecture - in OSSM and elsewhere * Decision completed on whether a new operator is required, especially for upgrade and status reports * Decision completed on whether Ingress->Gateway (or Route->Gateway) translation is needed * Enhancement Proposals, Migration details, Tech Enablement, and other input for QA and Docs * API server integration, Installation, CI, E2E tests, Upgrade details, Telemetry Dependencies (internal and external) # OSSM release schedule aligned with OpenShift's cadence, or workaround designed # ...tbd h2. Previous Work (Optional): # https://issues.redhat.com/browse/NE-993 h2. Open questions:: # … h2. 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> |
New:
h1. Epic Goal
* Add Gateway API via Istio Gateway implementation as GA in future release *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. *GA:* A feature is implemented as GA so that developers can issue an update to the Tech Preview MVP and: * can no longer change APIs without following a deprecating or backwards compatibility process. * are required to fix bugs customers uncover * must support upgrading the cluster and your component * provide docs * provide education to CEE about the feature * must also follow Red Hat's support policy for GA h2. 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. h2. Scenarios # ... h2. Acceptance Criteria * Gateway API and Istio Gateway are in an acceptable standing for GA * Istio Gateway installation without sidecars enabled * TBD * Enhancement Proposals, Migration details, Tech Enablement, and other input for QA and Docs * API server integration, Installation, CI, E2E tests, Upgrade details, Telemetry Dependencies (internal and external) # OSSM release schedule aligned with OpenShift's cadence, or workaround designed # ...tbd h2. Previous Work (Optional): # https://issues.redhat.com/browse/NE-993 # https://issues.redhat.com/browse/NE-1036  # h2. Open questions:: # … h2. 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> |
| Epic Name | Original: Add Tech Preview Support for Gateway API via Istio | New: Add GA Support for Gateway API via Istio |