"nginx.org/rewrites" requires a very strict format; can it be relaxed?

[ronchalant]

Is your feature request related to a problem? Please describe.
nginx.org/rewrites rules formatting is very strict - you cannot have a whitespace before the serviceName when multiple rules are entered.

For example if it's defined this way:

"serviceName=a rewrite=/a; serviceName=b rewrite=/b;serviceName=c rewrite=/c"

Then a and c are picked up, but because the b rule has a leading space it doesn't get picked up.

Describe the solution you'd like
It would be good to have this strict-formatting relaxed a bit, supporting the existing semicolon-separated strings with better handling of whitespaces, but also perhaps other native-YAML array formats.

Some samples/suggestions below:

Multiline string

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.org/rewrites: >
      serviceName=a rewrite=/a;
      serviceName=b rewrite=/b;
      serviceName=c rewrite=/c;

if the existing rule definitions were maintained but whitespaces were better handled the above would be usable

As YAML array of objects

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.org/rewrites: 
    - serviceName: a 
      rewrite: "/a"
    - serviceName: b
      rewrite: "/b"
    - serviceName: c 
      rewrite: "/c"

Describe alternatives you've considered
It works as-is if you remove white-spaces, but if you have many rules it becomes harder to read/manager.

[pleshakov]

@ronchalant thanks for report.

I've created a PR #389 that improves parsing of the rewrites annotation. Now the whitespace is handled better.

    nginx.org/rewrites: >
      serviceName=a rewrite=/a;
      serviceName=b rewrite=/b;
      serviceName=c rewrite=/c;

that's definitely more usable then a single string. Thanks for the example.
with the PR, this is possible now.

Regarding As YAML array of objects. In the long-term we plan to migrate from annotations to our own YAML spec.

Btw, right now there is a way to split one Ingress resource into multiple with mergeable Ingress resources. If some annotation cannot be applied per service, you can still use that annotation on per service basic if you split the Ingress into multiple Ingresses.

[ronchalant]

thanks @pleshakov - I'll take a look at the mergeable Ingress resources.

[pleshakov]

the PR with a fix #389 was merged. The fix is available in the edge version -- https://github.com/nginxinc/kubernetes-ingress/#nginx-ingress-controller-releases

[Dean-Coakley]

Closing, this fix is now available in the latest stable release