Unable to use Load Balancer's IP address for the ingress gateway #361
Comments
|
We think the issue is that the url being submitted to traefik is wrong because it is in fact not a valid ipv4 address: Is it an option to turn the address around and let it be |
|
I agree with your thinking ;) |
|
@Gmerold: I see that the documentation is using |
|
Hello @mmkay, which documentation do you mean? SD-Core? |
|
Currently, the ingress library is using We could solve this by either contributing a change upstream to pydantic (so that |
|
I think what @PietroPasotti is getting at is that the linked doc uses Doing some pure pydantic testing (not with traefik's lib, just pydantic itself), we can see: from pydantic import BaseModel, AnyHttpUrl, ValidationError
class MyModel(BaseModel):
url: AnyHttpUrl
# Will pass validation
MyModel(url="http://valid.com") # a control
MyModel(url="http://valid.com1") # Valid even though it ends with a number
MyModel(url="http://10.0.0.4.nip.io")
MyModel(url="http://sdcore-nms.10.0.0.4.nip.io")
# Will fail validation
try:
MyModel(url="http://invalid url") # a control
except ValidationError:
pass
else:
raise Exception("I should have failed")
try:
# fails because last segment is entirely numeric
MyModel(url="http://sdcore-nms.10.0.0.4")
except ValidationError:
pass
else:
raise Exception("I should have failed")This feels consistent with other places too. For example, type So having said all that (and having not actually looked at the traefik charm), is the missing |
|
Hi @sed-i, |
|
Can this issue be prioritised? Every deployment of our charmed 5G deployment is affected by it. In addition, our tutorials and documentation look bad as we're having to reference this issue and let users know that it's expected for traefik to be an error state. Reference: |
|
@dstathis can you please make sure this is included in the pulse that starts on Monday? Thanks. |
|
Yup no problem |
|
I think the issue here is just misconfiguration. Traefik has two
If you're using the loadbalancer IP as the domain, then subdomain really isn't valid (since mymodel.myapp.1.2.3.4) isn't a valid domain based on the above conversation. Feels like Is there a reason why |
|
This kinda reminds me a story of my buddy. He used to have a car with a broken gearbox; only second and fourth gear would work. One day I had to drive this car and obviously I wanted to start with a first gear. After I struggled for a short while, my buddy told me to use the second gear instead. After starting on a second gear, I had to push the RPMs really high to be able to change to fourth gear directly, because the third wouldn't work as well. When I asked him about fixing the gearbox, he was like "nah, two of them still work". |
|
Yes agreed, the root issue here is that if |
…outing_path Previously, this charm accepted the following configuration: * routing_mode=subdomain * external_hostname="" # (unset) When external_hostname is unset, the url provided for any application related by ingress uses the LoadBalancer's external address, which may be an IP. In these cases, it would provide charms urls like `model.app.1.2.3.4`, which are invalid URLs (the last segment of a URL cannot be all-numeric). This led to an uncaught pydantic validation error when calling `ipa.publish_url()` because that method includes validation of the URL, putting the charm in Error state. An example of this is shown in #361 Ideally, the fix here would be to validate the charm configuration+LoadBalancer details and halt charm execution if the configuration was invalid, putting the charm into BlockedStatus until resolved. The problem is that the current architecture of this charm makes that solution challenging. The charm is designed to atomically handle events (doing only the work a particular event needs) rather than holistically (recomputing the world on each event), meaning that skipping or losing track of events leads to undesired charm states. Also, `ipa.publish_url()` is called deep in most (all?) event handlers, making it difficult to properly handle these errors at the charm level without a major refactor of the charm. As a compromise, the following has been done: * the traefik_k8s/v2/ingress.py library's `publish_url` method has been updated to catch the pydantic validation error cited in #361 and log it rather than raise it to the charm. The library then writes ingress=None to the databag instead of the invalid URL, giving a soft indication to the user that the url is invalid. * the config.yaml descriptions for routing_mode and external_hostname have been updated to explain the incompatibility in these settings * config validation has been added to the __init__ of the charm for routing_mode and external_hostname. If routing_mode==subdomain and hostname is unset, the charm will log warnings for the user about the possible incompatibility (but will not block the charm) The upshot of these changes is that this charm will: * not go into an unresponsive error state * as best it can given the current charm architecture, warn the user of the misconfiguration * not risk losing events through defer or getting event sequencing wrong Fixes #361
…#420) Previously, this charm accepted the following configuration: * routing_mode=subdomain * external_hostname="" # (unset) When external_hostname is unset, the url provided for any application related by ingress uses the LoadBalancer's external address, which may be an IP. In these cases, it would provide charms urls like `model.app.1.2.3.4`, which are invalid URLs (the last segment of a URL cannot be all-numeric). This led to an uncaught pydantic validation error when calling `ipa.publish_url()` because that method includes validation of the URL, putting the charm in Error state. An example of this is shown in #361 Ideally, the fix here would be to validate the charm configuration+LoadBalancer details and halt charm execution if the configuration was invalid, putting the charm into BlockedStatus until resolved. The problem is that the current architecture of this charm makes that solution challenging. The charm is designed to atomically handle events (doing only the work a particular event needs) rather than holistically (recomputing the world on each event), meaning that skipping or losing track of events leads to undesired charm states. Also, `ipa.publish_url()` is called deep in most (all?) event handlers, making it difficult to properly handle these errors at the charm level without a major refactor of the charm. As a compromise, the following has been done: * the traefik_k8s/v2/ingress.py library's `publish_url` method has been updated to catch the pydantic validation error cited in #361 and log it rather than raise it to the charm. The library then writes ingress=None to the databag instead of the invalid URL, giving a soft indication to the user that the url is invalid. * the config.yaml descriptions for routing_mode and external_hostname have been updated to explain the incompatibility in these settings * config validation has been added to the __init__ of the charm for routing_mode and external_hostname. If routing_mode==subdomain and hostname is unset, the charm will log warnings for the user about the possible incompatibility (but will not block the charm) The upshot of these changes is that this charm will: * not go into an unresponsive error state * as best it can given the current charm architecture, warn the user of the misconfiguration * not risk losing events through defer or getting event sequencing wrong Fixes #361
|
#420 adds a fix to this, in that we now clearly state that this charm should not be deployed with #420 stops short of actually putting the charm into BlockedStatus and forcing a user to avoid this setting combination. tl/dr: the current architecture of the charm makes actually blocking on bad config difficult. There's a near-term plan (definitely this sprint, probably in the next month or two) to refactor the charm entirely and hopefully address this better, but for now we get just the warnings. |
Bug Description
New version of
pydantic-corebreaks falling back to the Load Balancer's IP for the ingress gateway when theexternal-hostnameis not configured:Potential solution here could be using nip.io to pretend LB IP is a legit URL (e.g.
10.0.0.2.nip.io)To Reproduce
https://canonical-charmed-aether-sd-core.readthedocs-hosted.com/en/stable/tutorials/getting_started/
Environment
Juju 3.4
Microk8s 1.27-strict/stable
Traefik latest/stable
Relevant log output
Additional context
No response
The text was updated successfully, but these errors were encountered: