-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: add ingress_per_unit integration to glauth-k8s-operator #78
base: main
Are you sure you want to change the base?
feat!: add ingress_per_unit integration to glauth-k8s-operator #78
Conversation
Signed-off-by: Jason C. Nucciarone <[email protected]>
BREAKING CHANGES: Updates the return type of the `ldap_url` property from `LdapIntegration` to `List[str]` from `str` to support retrieving multiple ingress urls for `glauth-k8s`. Ingress is required for glauth-k8s to be publicly addressable from outside Kubernetes. Does not change the `ldap` interface implementation as `url` was already provided as a list object within the `ldap` charm library, so it just moves the `List[str]` type casting in `provider_data`. Signed-off-by: Jason C. Nucciarone <[email protected]>
def ldap_url(self) -> List[str]: | ||
if ingress := self._charm.ingress_per_unit.urls: | ||
return [f"ldap://{url}" for url in ingress.values()] | ||
else: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a minor nitpick: We don't need the else
.
def ldap_url(self) -> str: | ||
hostname = self._charm.config.get("hostname") or socket.getfqdn() | ||
return f"ldap://{hostname}:{GLAUTH_LDAP_PORT}" | ||
def ldap_url(self) -> List[str]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a minor nitpick on naming: probably then we could rename it to ldap_urls
?
(I could be wrong) Another minor thing is about the reason that ldap_url
was changed to a container type initially. @nsklikas has more authority to clarify that. I remember it's somehow related to glauth proxy usage.
What I worry here is that this data container will represent inconsistent meanings when integrating with traefik or not (in a proxy mode).
Let me know if I am wrong :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it was related to https://github.com/canonical/ldap-integrator/.
The reason is that glauth accepts a list of URLs when configuring it to acts as an ldap proxy (see https://glauth.github.io/docs/backends.html). When making an ldap request to the external server, tries to call them one by one, until one the requests succeeds.
I agree with the name change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renaming the property to ldap_urls
sounds good to me. Getting a list of possible endpoints for the LDAP server is also ideal for SSSD as you can configure to switch server endpoints if one endpoint fails: https://manpages.ubuntu.com/manpages/oracular/en/man5/sssd-ldap.5.html#failover.
Glauth high-availability is also achieved by having multiple running instances of Glauth functioning as their own individual endpoint, but share the same database backend.
@@ -97,6 +98,13 @@ def __init__(self, *args: Any): | |||
extra_user_roles="SUPERUSER", | |||
) | |||
|
|||
self.ingress_per_unit = IngressPerUnitRequirer( | |||
self, | |||
"ingress", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a minor nitpick:
We usually put constant integration names in the constants.py
. It would be nice to follow that. Thank you.
LGTM overall. Thank you for the contributions. Just have a small concern about that |
@@ -97,6 +98,13 @@ def __init__(self, *args: Any): | |||
extra_user_roles="SUPERUSER", | |||
) | |||
|
|||
self.ingress_per_unit = IngressPerUnitRequirer( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just have a question:
Do we need to subscribe the ready and revoked events to update the ldap
integration databag if there are any existing ldap
integrations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... we likely should handle those events as this will change the address requirers utilize to contact the Glauth server. Simple netcat
scan indicates that other pods can communicate with the open port on the on the load balancer:
# 10.0.0.135 is the address that traefik-k8s grabbed from MetalLB.
root@loki-0:/$ nc -zv 10.0.0.135 3893
Connection to 10.0.0.135 3893 port [tcp/*] succeeded!
We'll need to check if any requirers have joined the ldap
relation and update the databag.
Followed the steps, and encountered an error from traefik when I scaled up glauth. The health check of traefik also fails. scaling down to 1 unit turns traefik back to healthy.
Not sure if this only happens to me. Already let Jason know. |
Someone also hit this problem: canonical/traefik-k8s-operator#406 This is due to the fact that traefik ingress-per-unit TCP model in current implementation will use the port (passed from the requirer charm) to open the listening port for exposing the unit. If more units come up, traefik will complain because it tries to open the same port for other units. |
Easiest fix here is just not scaling This shouldn't be a blocking requirement for merging this PR, but it should be fixed in traefik-k8s since other charms are running into this issue. Given that the ingress urls already have the port provided in the returned urls, might just make sense for |
This PR adds the
ingress_per_unit
integration to glauth-k8s so that theglauth
TCP service can be addressable from machine charms outside of the Kubernetes cluster. Now, when a machine charm wants to connect toglauth
for LDAP goodness, all you need to do is integrate glauth-k8s with traefik:Breaking changes
One thing to note is that I updated the function signature of the
ldap_url
to returnList[str]
instead ofstr
. I don't think it's that much of an issue asldap_url
is only used two times within the operator, and its returned value was casted toList[str]
to satisfy the type requirements for theurls
field in theldap
interface.Related issues