Comments (4)
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).
from smi-spec.
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.
from smi-spec.
+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).
from smi-spec.
+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.
from smi-spec.
Related Issues (20)
- when to validate traffic target
- `Matches` in `TrafficSplit` is unclear HOT 12
- Add the (required) `apiVersion` field to all YAML file examples HOT 1
- Clarify behavior of overlapping rules and routing resolution in TrafficSplit HOT 1
- Support API/Interface
- Support Exact and Prefix matches for URI path in HTTPRouteGroup
- The Header Match format in HTTPRouteGroup description is not consistent with smi-sdk-go HOT 2
- TrafficTarget should be created in same namespace as destination
- No warning if incorrect yaml is applied for Traffic Split HOT 1
- Logical relationships between multiple match condition in TrafficSplit resource HOT 1
- Trafficsplit based on sourcelabel? HOT 3
- CRD installation HOT 1
- support queryParams in TrafficSpec HOT 1
- Question about A/B testing with traffic splits HOT 1
- Does the TrafficSplit spec allow for identification of a default route for unmatched traffic? HOT 3
- Depreciation of TrafficRoutes in favor of supporting Kubernetes Gateway API - WIP HOT 7
- Question: Header-based TrafficSplit
- Any plans for mirroring?
- State of SMI Spec HOT 6
- CNCF TOC annual review due HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from smi-spec.