Fixes adding unwanted routes from additional-hostnames
On multiple ingress relations for different service-hostnames (foo, bar),
if the first relation has "bar" as an additional-hostname, it will wrongfully
have the routes from the second relation.
This is happening because the same list of ingress paths are being used
for all host-names and additional-hostnames.
When creating the Ingress Objects, a separate path list list is created for
each hostname.
Adds multiple ingress relations support
Removes the 1 limit from metadata.yaml
Currently, the Ingress Name is based on the service-name. However, that
name can be a bit inconsistent when it comes to having multiple relations.
Changes the Ingress Name used to app.name-ingress.
The nginx/nginx-ingress Controller typically used in EKS doesn't handle
multiple Kubernetes Ingress Resources having the same hostname in the same
way as the k8s.gcr.io/ingress-nginx/controller:v1.1.0 Controller used in
microk8s. The former doesn't handle them at all, unless you specify certain
annotations, and an additional Kubernetes Ingress Resource [1]. But both
Controllers can handle one Kubernetes Ingress Resource containing multiple
hosts / routes.
This charm will now group all the Ingress rules by the required hostnames
from all the relations (with config option overrides) and create Kubernetes
Ingress Resources per required hostname. When a relation is broken, its
ingress-related data will be removed from the Ingress Resources. If no
relation will require a particular Ingress Resource anymore, it will be
removed.
Creates a single Kubernetes Ingress Resource containing all the hosts and
path rules from all the relations (with config option overrides). When
a relation is broken, its ingress-related data will be removed from the
Ingress Resource. If there are no relations left, the Resource will be removed.
Adds TLS information for each additional-hostname defined (each new hostname
has its own Kubernetes Ingress Resource).
On multiple relations, if we're required to have different annotations
on the same Ingress Resource (same hostname), we cannot satisfy that
request. In this case, we enter BlockedStatus.
On multiple relations, if there are multiple matching route paths on the
same hostname, we enter BlockedStatus.
Adds unit tests to validate the cases in which multiple relations are being
used.
On multiple relations, we should use the service-name, service-port,
and route-paths from the relation data fist, instead of reading them
from the config options first. This will prevent us from having
Service name conflicts and route path conflicts.
If there is only one relation, the config option will still override
the relation data (to maintain backwards compatibility).
[1] https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/mergeable-ingress-types
