You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are pretty heavy users of map-files where we (for example) keep a list of allowed IP-numbers. These map-files is currently deployed using a special ConfigMap key that gets mounted as it's own file.
This file is then used in various Ingress-annotations like this;
Might be incompatible when running haproxy-ingress as non-root
Might be incompatible when running in chroot
We are primarily affected by the first two points - even though (2) is more of an annoyance. I haven't verified if the last two is actually valid issues.
What HAProxy Ingress should do or how it should behave differently
The solution I would be looking for is really twofold and heavily inspired from what I read in haproxytech docs;
First, haproxy-ingress would need to be aware of such custom map-files internally somehow. For example by a cmd-line argument naming the ConfigMap used for custom-maps. (I.e. --configmap-custom-maps=$(POD_NAMESPACE)/custom-maps)
Then all relevant configuration key's that could benefit from reading their values from a map-file would get an alternative way to set their values to indicate that the value should come from a file.
For example, with the above example using a map-file look like something like this;
What are you trying to do
We are pretty heavy users of map-files where we (for example) keep a list of allowed IP-numbers. These map-files is currently deployed using a special ConfigMap key that gets mounted as it's own file.
This file is then used in various Ingress-annotations like this;
This works well for the most part, but has a few shortcomings;
Path
-scopeWe are primarily affected by the first two points - even though (2) is more of an annoyance. I haven't verified if the last two is actually valid issues.
What HAProxy Ingress should do or how it should behave differently
The solution I would be looking for is really twofold and heavily inspired from what I read in haproxytech docs;
First, haproxy-ingress would need to be aware of such custom map-files internally somehow. For example by a cmd-line argument naming the ConfigMap used for custom-maps. (I.e.
--configmap-custom-maps=$(POD_NAMESPACE)/custom-maps
)Then all relevant configuration key's that could benefit from reading their values from a map-file would get an alternative way to set their values to indicate that the value should come from a file.
For example, with the above example using a map-file look like something like this;
The prefix of the value (in this example
custom-maps/
) decides if it should be parsed as a string or path to a maps-file.This would ensure the annotation still supports the current syntax;
The text was updated successfully, but these errors were encountered: