spec how to separate the istio-pilot charm into two charms, an istio daemon and an istio integrator

[ca-scribner]

Context

The current istio-pilot charm combines 2+ functions:

1. deploying and managing the istio daemon (everything you get from istioctl install ...
2. functioning as an integrator between charms and istio by:
   1. providing ingresses (by creating VirtualServices) through the gateway provided by a related istio-ingressgateway charm
   2. (kinda related to (i)) securing the ingress via auth w/dex, etc, when required

Because these functions are delivered through the same charm, (especially (1) with the others), we have a few pain points:

1. the istio-pilot charm is complicated (install and upgrade affect istio daemon, config-change affects everything, relation changed affects ingresses, ...)
2. Kubeflow always ships with its own istio, thus:
   • charmed kubeflow cannot use the existing istio in the cluster
   • istio is deployed in the Kubeflow namespace, which has implications on configuring istio's policies

To improve this situation, it is proposed that we separate istio-pilot into two charms (names tbd):

• istio: deploys and manages the istio daemon
• istio-integrator: provides routes through an ingress, other things charms need from istio

Important points to consider:

• the migration from current (one-charm) state to two-charm state should be planned and tested. We need to support migration between these states, either automatically or through manual instructions
• the integrator should work with the new istio(-daemon) charm and istio that is deployed without charms

What needs to get done

1. research and design the two-charm istio solution
2. write a spec
3. (stretch) prototype the upgrade procedure

Definition of Done

1. an approved spec

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-5200.

This message was autogenerated

[ca-scribner]

More decisions on this pending on #377