Ingress Trait to support an array on the path

[cfitzw]

Requirement

Would like to set multiple paths and/or aliases for an integration.

Problem

Currently unable to utilize the ingress trait on an integration to set multiple paths for the ingress to consume.

It appears this is possible/supported via kubernetes documentation:
https://kubernetes.io/docs/concepts/services-networking/ingress/#examples

Proposal

Allow and array on ingress.path ([]string):
https://camel.apache.org/camel-k/2.5.x/apis/camel-k.html#_camel_apache_org_v1_trait_IngressTrait

Open questions

No response

[squakez]

Thanks for the feature request. Are you planning to work on this by any chance?

[cfitzw]

@squakez - I would very much like to try -- I'll take a walk through the developer's guide and see if I can work through how to implement the changes.

[cfitzw]

Good progress so far, documentation has been excellent. I should be able to get a PR submitted in the coming days.

[squakez]

Good progress so far, documentation has been excellent. I should be able to get a PR submitted in the coming days.

Excellent. Just let us know if you have any doubt or you need any help!

[cfitzw]

TL;DR - I think this is bubbling up into a bigger issue.

@squakez I have a working build (Draft PR #5996) , allowing a string array on the ingress.path, however, I have some doubts...

1. This would become a breaking change == any integration having an ingress.path=<string> set would break.
   Possibly some code could be implemented to auto-convert string into array... but maybe not worth the effort based on below.
2. This isn't fully solving the problem... IMO, the IngressTrait should follow the APIs hierarchy, starting from here:
   https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#ingressspec-v1-networking-k8s-io
   This would allow any number of IngressRules (which has it's own sub-structure), meaning, you could specify multiple hosts, and for those hosts, multiple paths, which may also have their own associated pathType.

Best visual example of the hierarchy (from https://v1-30.docs.kubernetes.io/docs/concepts/services-networking/ingress/#hostname-wildcards):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-wildcard-host
spec:
  rules:
  - host: "foo.bar.com"
    http:
      paths:
      - pathType: Prefix
        path: "/bar"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: "*.foo.com"
    http:
      paths:
      - pathType: Prefix
        path: "/foo"
        backend:
          service:
            name: service2
            port:
              number: 80

Please let me know your thoughts.

[squakez]

First of all thanks for the effort to put on a draft @cfitzw, really appreciated. About the specific problems you're mentioning:

1. Indeed, we cannot transform the usage of path as it introduce a compatibility problem. What we can do, however, is to introduce a new one, ie, paths that will hold the new logic. Eventually we can deprecate path in favor of paths if we see it makes sense.
2. If the goal of the feature is to support multiple paths and hosts, then, we may rework entirely the feature and allow the user to introduce a given syntax, eg, -t ingress.rules=foo.bar.com/bar -t ingress.rules=*.foo.com/foo which would translate into the Ingress structure you've highlighted.

I am not entirely sure what exactly you need to support, but I think we can separate this issue to work both on 1 and, if that makes sense, on 2, providing a different parameter for each feature we want.

[cfitzw]

@squakez -- thank you for the feedback.

I've implemented number 1 and committed to the PR.

In regards to number 2, this is not a desired need at-the-moment, so let's focus on adding support for number 1 and this can become a new issue/PR at a later point-in-time.