Epic Goal

Replace the Istio deployment for Gateway API support on OCP to use directly generated manifests instead of using Sail Operator and OLM

Why is this important?

The current approach of installing OSSM using an OLM subscription causes several problems:

• If the cluster-admin has already created a subscription for OSSM, it might conflict.
• If the cluster does not have OLM and the Marketplace capabilities enabled, it cannot install OSSM.
• Moving faster with Gateway API releases is harder as it is strictly dependent of OLM

Scoping

This EPIC must cover the following scope:

• Define with OSSM team the generation of manifests that will be used by CIO to install OSSM for Gateway API
  • MUST cover best practices: Deploy with less privileges, separate service accounts, deploy HPA for control plane and PDB for upgrades
• Define how to create/mutate the default Gateway Class
  • MUST have a ConfigMap attached to the default GatewayClass setting proper HPA and PDB for seamless upgrades
• Define how to get the images required for this deployment as part of the core payload
  • Control Plane - Pilot images
  • Dataplane - Envoy images
• Define how CRDs must be deployed
  • For Gateway API we should follow the standard channel with the current supported version
  • StorageVersion migration MUST be automated
  • For integration with RHCL/MCP Gateway and others, need to check how specific Istio CRDs must be deployed (WASMPlugin, EnvoyFilter, DestinationRule)
  • Establish a VAP and how to limit usage of EnvoyFilter and others on our case for authorized namespaces (optional for now)
• Define the upgrade process
  • For OLM managed to non-OLM managed - How to take over the resources created by Sail Operator without causing disruption - eg.: Once Istio resource is deleted, will there be any problem?
  • For different versions of non-OLM managed - What are the scenarios that needs to be taken care? How to not cause disruptions?

How 

• Watch gatewayclasses, installplans, subscriptions, and istios.
• If a gatewayclass with the OpenShift controller name is observed, reconcile it as follows:

1. Ensure the servicemeshoperator3 OLM subscription.  
2. Approve any installplan for the servicemeshoperator3 subscription.  
3. Ensure the Istio CR.  

This gatewayclass controller will need to be modified to implement the following logic:

• Watch gatewayclasses and deployments.  
• If a gatewayclass with the OpenShift controller name is observed, reconcile it as follows:

1. If an Istio CR already exists, perform a migration.  
2. Otherwise, ensure the istiod deployment. (And other resources)

The migration logic needs to achieve the following goals:

• Replace, or transfer ownership of, the existing istiod deployment from one managed by Sail Operator to one managed by CIO.  
• Remove the Istio CR.  
• Open question: Are there other resources we want to remove?

• Avoid or minimize data-plane disruption (that is, Envoy, and client connections to it).  

Out of scope:

• The migration logic does not need to remove any existing servicemeshoperator3 subscription or deployment.  
• This is an unnecessary risk.  A customer might be using OSSM and have additional Istio CRs in addition to the one that CIO configures.
• However, we should document that the cluster-admin has the option of removing the subscription after migration. 

Planning Done Checklist

The following items must be completed on the Epic prior to moving the Epic from Planning to the ToDo status:

• Priority is set by engineering
• Epic must be Linked to a Parent Feature
• Target version must be set
• Assignee+ must be set
• (Enhancement Proposal is Implementable
• (No outstanding questions about major work breakdown
• (Are all Stakeholders known? Have they all been notified about this item?
• Does this epic affect SD? Have they been notified? (View plan definition for current suggested assignee)
  1. Please use the “Discussion Needed: Service Delivery Architecture Overview” checkbox to facilitate the conversation with SD Architects. The SD architecture team monitors this checkbox which should then spur the conversation between SD and epic stakeholders. Once the conversation has occurred, uncheck the “Discussion Needed: Service Delivery Architecture Overview” checkbox and record the outcome of the discussion in the epic description here.
  2. The guidance here is that unless it is very clear that your epic doesn’t have any managed services impact, default to use the Discussion Needed checkbox to facilitate that conversation.

Additional information on each of the above items can be found here: Networking Definition of Planned

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)

1. …

Open questions

1. Does Sail Operator do anything special during upgrade to prevent disruption that cluster-ingress-operator would need to replicate?
2. …

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>