lp:~cbelu/charm-k8s-ingress

Author: Claudiu Belu
Author Date: 2022-02-24 10:51:36 UTC

Improves the test code coverage

There are a few cases in which the test coverage could be improved.

Author: Claudiu Belu
Author Date: 2022-02-24 09:57:40 UTC

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.

Author: Claudiu Belu
Author Date: 2022-02-24 08:15:46 UTC

Fixes Resource creation on missing relation data

At the moment, the charm will attempt to create Kubernetes Resources for
relations which do not have relation data set yet in the multiple relations
scenario. This will result in errors trying to create Services with invalid
fields (e.g.: Service Port: Invalid value: 0: must be between 1 and 65535)

Skip adding resources for relations we don't have valid data from.

Author: Claudiu Belu
Author Date: 2022-02-10 15:19:42 UTC

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