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.
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.
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.
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.
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).
Refactors charm for adding multiple relations support
Updates IngressBrokenEvent to be based on RelationEvent, and
include the relation in the event data, which will help us
determine which relation has been broken.
Separates the config / relation data into the _ConfigOrRelation object,
which receives the config and a relation in its constructor. This will allow
us to get necessary data from a specific relation (which is overriden by the
config options).
2 branches
proposed for merging into this one.
