Juju overwrites existing Ingress on cluster restart

[Kenneth Koski]

This is related to the limitations from https://bugs.launchpad.net/juju/+bug/1849725

I have a charm that I'd like to expose via HTTPS. I can't do that with regular `juju expose`, so I edit the Ingress that Juju creates to add a TLS section. That works fine, until a cluster restart, e.g. `sudo snap stop microk8s && sudo snap start microk8s`. Juju then boots up and overwrites the existing Ingress with what it expects to be there, removing the TLS section.

The overall solution is to fix the related limitation for `juju expose`, but until that happens, the exact bug here is that I'd expect Juju to not overwrite the existing Ingress if it already exists (based on reading what looks to be the relevant source: https://github.com/juju/juju/blob/f0871dbf96db0c58ec2df8f9e32dbe1bbd47a476/caas/kubernetes/provider/ingress.go#L75), or at least log about it better, as I had to turn on TRACE logging and fight through 100's of K's of logging lines.

[Ian Booth (wallyworld)]

FWIW, the charm can ask for a bespoke Ingress Resource via the k8s specific YAML with pod-spec-set

That should avoid the need to juju expose, which is more limited; juju expose originally just opened a firewall port for non-k8s models and doesn't have the modelling semantics to do more complex things in k8s.

kubernetesResources:
  ingressResources:
    - labels:
        foo: bar
      annotations:
        nginx.ingress.kubernetes.io/rewrite-target: /
      spec:
        rules:
        - http:
            paths:
            - path: /testpath
              backend:
                serviceName: test
                servicePort: 80

[Tim Penhey (thumper)]

Due to design work in this space, moving to -next for now.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.