CH-243: Make route pattern customizable

[iamludal]

Closes CH-243

Implemented solution

Make the route pattern customizable on the app level, as well as globally.

How to test this PR

Change the route pattern of an app and try to reach it

Sanity checks:

• The pull request is explicitly linked to the relevant issue(s)
• The issue is well described: clearly states the problem and the general proposed solution(s)
• In this PR it is explicitly stated how to test the current change
• The labels in the issue set the scope and the type of issue (bug, feature, etc.)
• The relevant components are indicated in the issue (if any)
• All the automated test checks are passing
• All the linked issues are included in one Sprint
• All the linked issues are in the Review state
• [ x] All the linked issues are assigned

Breaking changes (select one):

• The present changes do not change the preexisting api in any way
• This PR and the issue are tagged as a breaking-change and the migration procedure is well described above

Possible deployment updates issues (select one):

• There is no reason why deployments based on CloudHarness may break after the current update
• This PR and the issue are tagged as alert:deployment

Test coverage (select one):

• Tests for the relevant cases are included in this pr
• The changes included in this pr are out of the current test coverage scope

Documentation (select one):

• The documentation has been updated to match the current changes
• The changes included in this PR are out of the current documentation scope

Nice to have (if relevant):

• Screenshots of the changes
• Explanatory video/animated gif

[filippomc]

better do | quote

[zsinnema]

question: is it correct that I'm missing a backwards compatible fallback value for the route_pattern value? I mean incase the application doesn't set any imho it should default to "/"

suggestion: I would go for the Traefik regular expression as default format/setting (K8s ingress nginx controller is deprecated).

[iamludal]

question: is it correct that I'm missing a backwards compatible fallback value for the route_pattern value? I mean incase the application doesn't set any imho it should default to "/"

suggestion: I would go for the Traefik regular expression as default format/setting (K8s ingress nginx controller is deprecated).

Regarding your question, I think it should be backward compatible as I added a route_pattern field in the default values file of the chart, with a default value of /(.*) (the current implementation). If you think I didn't put it in the correct file please let me know, I can also add a second fallback value to be very sure.

As for Traefik, do you mean they handle regex differently, or do you mean to use the PathRegex syntax instead of the current one?

[zsinnema]

question: is it correct that I'm missing a backwards compatible fallback value for the route_pattern value? I mean incase the application doesn't set any imho it should default to "/"
suggestion: I would go for the Traefik regular expression as default format/setting (K8s ingress nginx controller is deprecated).

Regarding your question, I think it should be backward compatible as I added a route_pattern field in the default values file of the chart, with a default value of /(.*) (the current implementation). If you think I didn't put it in the correct file please let me know, I can also add a second fallback value to be very sure.

As for Traefik, do you mean they handle regex differently, or do you mean to use the PathRegex syntax instead of the current one?

Ah yes, you are right about 1. That's indeed the default fallback
About 2. yes I think it's a different format, not sure. May be you can have a look how they handle regex in path routes

[iamludal]

question: is it correct that I'm missing a backwards compatible fallback value for the route_pattern value? I mean incase the application doesn't set any imho it should default to "/"
suggestion: I would go for the Traefik regular expression as default format/setting (K8s ingress nginx controller is deprecated).

Regarding your question, I think it should be backward compatible as I added a route_pattern field in the default values file of the chart, with a default value of /(.*) (the current implementation). If you think I didn't put it in the correct file please let me know, I can also add a second fallback value to be very sure.
As for Traefik, do you mean they handle regex differently, or do you mean to use the PathRegex syntax instead of the current one?

Ah yes, you are right about 1. That's indeed the default fallback About 2. yes I think it's a different format, not sure. May be you can have a look how they handle regex in path routes

It seems like regex are handled as regular regex using the PathRegexp syntax, see https://doc.traefik.io/traefik/v3.0/routing/routers/#path-pathprefix-and-pathregexp.

So I changed the manifest itself to be compatible with the Traefik ingress controller by adding the traefik.ingress.kubernetes.io/router.pathmatcher: PathRegexp annotation.

See: https://doc.traefik.io/traefik/reference/routing-configuration/kubernetes/ingress/#on-ingress

[iamludal]

This Traefik doc says that Regex are using this lib, so Regex should follow the syntax accepted by RE2.
I need to update the doc to make the exclusion example working with this syntax.