Juju overwrites existing Ingress on cluster restart
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Low
|
Unassigned |
Bug Description
This is related to the limitations from https:/
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:/
Changed in juju: | |
milestone: | none → 2.8-beta1 |
importance: | Undecided → Medium |
status: | New → Triaged |
Changed in juju: | |
milestone: | 2.8-beta1 → 2.8.1 |
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.
kubernetesResou rces:
nginx. ingress. kubernetes. io/rewrite- target: /
backend:
serviceName: test
servicePort: 80
ingressResources:
- labels:
foo: bar
annotations:
spec:
rules:
- http:
paths:
- path: /testpath