Testing out the `snappass-test` sidecar/pebble charm demo, I note that the default `juju expose` behaviour that would deploy an ingress in the case of a normal k8s charm does not work.
For example, provisioning the `mariadb-k8s` charm on microk8s and exposing it works as expected (creates an Ingress)
Note that this is using the juju branch found here: https://github.com/benhoyt/juju/tree/demo-pebble to enable sidecar charm deployment
Steps to reproduce:
```
# Configure MicroK8s
microk8s enable dns storage ingress
juju bootstrap microk8s micro
#
# Demonstrate expected behaviour with existing Charm
#
# Deploy MariaDB-k8s
juju add-model db
juju deploy cs:~charmed-osm/mariadb-k8s
# Configure
juju config mariadb-k8s kubernetes-ingress-class=nginx
juju config mariadb-k8s juju-external-hostname="db.dev"
juju expose mariadb-k8s
# Confirm ingress presence
kubectl -n db get ingress
#
# Demonstrate unexpected behaviour with snappass
#
juju add-model snappass
juju deploy snappass-test --resource snappass-image=benhoyt/snappass-test --resource redis-image=redis
# Configure
juju config snappass-test kubernetes-ingress-class=nginx
juju config snappass-test juju-external-hostname="snappass.dev"
juju expose snappass-test
# Ingress not created
kubectl -n snappass get ingress
```
As far as I can tell, there is no magic in the mariadb-k8s charm that is manually creating an ingress, and the behaviour is described as more generic in the Juju docs (https://juju.is/docs/kubernetes).
Possibly related to: https://github.com/canonical/operator/issues/487
Thanks for the report. We chose to stop working on this issue a few months ago, this is definitely a high priority for the sidecar charms, but we wanted to get the modeling correct on this one.
I've marked it for 2.9.1 so its high on out list.