trafficsplit: Behavior with conflicting TrafficSplit instances

[olix0r]

What is the expected behavior when multiple traffic split resources refer to the same apex service?

For example, given an apex service:

---
apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata:
  name: blue-green
spec:
  service: apex
  backends:
  - service: blue
    weight: 10m
  - service: green
    weight: 90m

---
apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata:
  name: red-yellow
spec:
  service: apex
  backends:
  - service: red
    weight: 10m
  - service: yellow
    weight: 90m

An implementation could choose to merge these traffic splits so it becomes effectively:

spec:
  service: apex
  backends:
  - service: blue
    weight: 10m
  - service: green
    weight: 90m
  - service: red
    weight: 10m
  - service: yellow
    weight: 90m

Or, we could dictate that this is illegal and require a validating admission controller to enforce service uniqueness.

Or, we could modify the spec to require that the TS resource name must match the apex service name...

This behavior should not remain undefined, however.

[michelleN]

+1 to resolving this ambiguity

In this example, it looks like the TS resource name gets used to describe the deployment strategy and this scenario makes it seem that there may be multiple strategies for the same service but for different version combinations of that service. Is that a valid user scenario? I can't think of an instance of a deployment strategy where this actually happens. I would think you'd want to describe traffic splitting between service versions in a single source of truth (one TrafficSplit resource instance).

[grampelberg]

Most of the user stories I can come up with boil down to misconfiguration. I personally like the idea of using a validation webhook as we'd be able to use that for more things (like service mesh feature support).

[billyshambrook]

One user scenario we have for this is to do with "branch" deployments whereby you want to create a unique deployment of a service for each feature branch that is open for engineers to test their changes before merging to "main" branch.

In a microservice environment it's tricky to deal with routing traffic through the services but wanting a particular request to hit a specific "branch" deployment for a given service.

One way we are solving this is by using header based routing. When we deploy the "branch" environment for Service B we add an additional routing logic to only receive requests with the header x-review:my-branch-name. When an engineer makes a request to Service A with that header, the request will go to the "main" branch deployment of Service A. If Service A then makes a request to Service B, Service A will passthrough the x-review:my-branch-name header to Service B. The service mesh would then see that header and route the request to the "branch" deployment of Service B.

We deploy each "branch" deployment as a separate Helm deployment so would be nice if we could have a separate TrafficSplit in each deployment which will reference the same service but introduce a new header backend route.

[michelleN]

+1 to the validating webhook idea. I'm for only having one traffic split per apex service for traffic split (up to TrafficSplit v1alpha2). Because we have routing based on HTTPRouteGroup in TrafficSplit v1alpha4, we can satisfy @billyshambrook's use case. For v1alpha3 of TrafficSplit and beyond I think we have to validate that the apex service + the match conditions are not the same as another Traffic Split but that can be tricky bc two match conditions may come from different sources but if you look at the details of the condition within the match, those might be the same.