feat: replace traefik with istio-ingress for public ingress

[wood-push-melon]

This pull request aims to drop traefik-k8s and use istio-ingress-k8s charm for public ingress.

Note:

• For internal ingress, we need the feature support in istio-ingress-k8s. Therefore, we are still using the traefik-k8s charm for it. We'll come back to it when istio-ingress-k8s charm supports that.

[nsklikas]

So no charm changes were required? Cool.

For the internal ingress my understanding was that we will drop that and use the mesh interface instead, or maybe I misunderstood?

@wood-push-melon @shipperizer should we keep tests for traefik to be sure that we don't break that integration or we no longer care about that??

[wood-push-melon]

So no charm changes were required? Cool.

For the internal ingress my understanding was that we will drop that and use the mesh interface instead, or maybe I misunderstood?

@wood-push-melon @shipperizer should we keep tests for traefik to be sure that we don't break that integration or we no longer care about that??

Yeah, no charm changes required generally. The ingress interface is reused.

(I might be wrong too) For the internal ingress, what I understand is that (at the current stage) we still need "something" to let the HTTPRoutes attach to, so that the traffic coming from other k8s clusters will get routed to different hydra listening ports. And this "something" will be another istio ingress (Gateway) at the current point. I saw there is some initiative called GAMMA, which lets us bind HTTPRoutes to k8s svc. It looks like an ongoing development.

I think we will no longer care about traefik in the future. But happy to hand it over to you two's decisions :)

[shipperizer]

So no charm changes were required? Cool.

For the internal ingress my understanding was that we will drop that and use the mesh interface instead, or maybe I misunderstood?

@wood-push-melon @shipperizer should we keep tests for traefik to be sure that we don't break that integration or we no longer care about that??

as discussed at standup, let s drop the internal ingress and use the service mesh

[wood-push-melon]

So no charm changes were required? Cool.
For the internal ingress my understanding was that we will drop that and use the mesh interface instead, or maybe I misunderstood?
@wood-push-melon @shipperizer should we keep tests for traefik to be sure that we don't break that integration or we no longer care about that??

as discussed at standup, let s drop the internal ingress and use the service mesh

yep, will make it in another PR.