Details
-
Spike
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
Description
This Spike covers two use cases:
- As an admin user of Service Mesh, I want to know how to turn on Gateway API and still maintain a single control plane.
- As an admin user of Gateway API, I want to know how to turn on Service Mesh and still maintain a single control plane.
Coordination between NE and OSSM teams needed. Discussion areas include:
- Namespaces probably determine managed (by c-i-o) vs unmanaged Gateways (whether in/outside openshift-ingress namespace)
- Decision - can we just always have service mesh enabled, but not watching every namespace? (check with Marc)
- Should we have cluster ingress operator install/configure the service mesh objects/control plane for mesh use cases?
Can we remove the adhoc installation of service mesh and make it easier to install via c-i-o?Can we create a shared Istio operator?- Others?
We need to decide what things need to be configurable by the cluster admin, and how the cluster admin would configure these things. To the latter point,
Consider adding a new OpenShift-specific config CRD to specify the following:
- Whether Gateway API/ingress is enabled.
- Whether Istio API/mesh is enabled.
Istiod profile.Automatic deployments (if this should be configurable).
The outcome of this story is some brief documentation including pros and cons of various methods to of configuring a new Gateway API installation while using Service Mesh, as well for as a new Service Mesh installation while using Gateway API; and a summary with a proposed recommended solution.
NE-1290 discusses various methods and features that could be configured.
Attachments
Issue Links
1.
|
Answer: Do we need to integrate with an existing service-mesh control-plane? | To Do | Unassigned |