Should SMI have an Ingress API? about smi-spec

[nicholasjackson]

So I agree that ingress should be external to the SMI spec as this is already extensively covered within the K8s spec. The v2 ingress proposal looks very comprehensive too.

I also think the spec contains enough detail for mesh aware ingresses to be configured from a routing perspective, however there is a gap around how do you configure the gateway to use the mesh? The answer at the moment is you use the custom CRD for your ingress of choice. My feeling is that this is an installation step and therefore belongs in the domain of the ingress provider.

There is a large amount of cross over however for example:

kind: HTTPRoute
name: split-traffic
spec:
  rules:
  - match:
      host: foo.com
      path:
        prefix: /app
    action:
      destination:
        backend:
        kind: networking.x-k8s.io/TrafficSplit
        name: split-traffic
---
kind: networking.x.k8s.io/TrafficSplit
name: traffic-split-backends
destinations:
- backend:
    name: my-service
  weight: 50
- backend:
    name: my-service-canary
  weight: 10

These two objects are incredibly similar to the SMI objects, while one controls the behaviour of the ingress and the other the service mesh, this is going to be incredibly confusing for the practitioner.

I also question at what point does k8s.networking introduce access policy, reliability patterns, etc.

Let me play devils advocate, I am wearing my fire proof suit, so comment away. "Should SMI maintain it's own HTTPRouteGroup and TrafficSplit or be rolled into k8s networking and this group collaborate on that API?"

^^ Note that is a question not an opinion, I am not sure I have an answer.

[grampelberg]

@danehans that's awesome, I'll be there!

[stefanprodan]

@lachie83 should we close this in favour of #123 ?

[danehans]

xref kubernetes-sigs/gateway-api#57

[danehans]

I agree with @nicholasjackson regarding #66 (comment). I have addressed the considerable overlap between the two projects in the Service APIs Slack channel here. I think it would be helpful if one or more SMI contributors can join a Service APIs community meeting to discuss how the two projects can potentially collaborate. I've added the topic to the agenda for our next meeting.

[danehans]

@grampelberg I made note of your attendance so we address #66 (comment) first.

[danehans]

@lachie83 should we close this in favour of #123 ?

+1 @stefanprodan