kosta1221 commented 2 years ago

What do you want to happen?

I have a use case where I want to store additional (custom) info per path in a rule. Currently the default nginx template produces location blocks in a limiting way. I would like to be able to parse additional properties about the backend supplied to the ingress itself, by using a CRD perhaps instead of the Ingress resource.

The relevant flow in location blocks production by the template:

The template calls the getIngressInformationmethod which parses the Ingress resource itself with 3 params: ingress, host and path. Host and path allow this method to get info about the specific backend.
Info about the specific method is used to set vars in the location block, but this is limited.

nginx vars in the location block which correspond to a specific backend are: $location_path, $service-name and $service-port which are what HTTPIngressPath consists of. If I add a custom prop per backend, and the go code which parses the resource yaml could somehow handle that to be used in a custom template or even in the default one, that could be very powerful.

Example Ingress yaml (this can perhaps be an extension of Ingress via CRD):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/configuration-snippet: |
      proxy_set_header My-Custom-Header $my_custom_prop;

spec:
  rules:
    - host: test-host.com
      http:
        paths:
          - path: /test(/|$)(.*)
            pathType: Prefix
            backend:
              service:
                mycustomprop: "mycustomvalue"
                name: test-service
                port:
                  number: 9000

In the custom template /etc/nginx/template/nginx.tmpl (or maybe even written generically to be supported in the default one):

...
location {{ $path }} {
            {{ $ing := (getIngressInformation $location.Ingress $server.Hostname $location.IngressPath) }}
            set $my_custom_prop   {{ $ing.MyCustomProp | quote }};
            set $namespace      {{ $ing.Namespace | quote }};
            set $ingress_name   {{ $ing.Rule | quote }};
            set $service_name   {{ $ing.Service | quote }};
            set $service_port   {{ $ing.ServicePort | quote }};
            set $location_path  {{ $ing.Path | escapeLiteralDollar | quote }};
            set $global_rate_limit_exceeding n;
...

Is there currently another issue associated with this?

Not that I have found one

k8s-ci-robot commented 2 years ago

@kosta1221: This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

k8s-triage-robot commented 2 years ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue or PR as fresh with /remove-lifecycle stale
Mark this issue or PR as rotten with /lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

kosta1221 commented 2 years ago

/remove-lifecycle stale

k8s-triage-robot commented 1 year ago