design upgrade procedure from previous istio (charmed or not) to this solution

canonical / istio-k8s-operator

https://charmhub.io/istio-k8s

Apache License 2.0

1 stars 1 forks source link

Open ca-scribner opened 3 months ago

ca-scribner commented 3 months ago

We need to design the upgrade procedure from another istio to this one. Some points to cover:

what if the Gateway CRDs already exist? Do we have conflicts during deployment?
how to we avoid deleting user data (eg: avoid deleting say the VirtualService CRD, which would delete all VirtualServices)
migrate charms using the old solution

dstathis commented 3 months ago

We should have an official upgrade path from the Kubeflow version of istio. We should also have a few tips for upgrading from generic installations.

dstathis commented 3 months ago

For the Kubeflow upgrade path, we should submit a PR to their repo which adds a config flag to not remove CRDs when the charm is removed.