Firstsawyou commented on pull request #2935:
URL: https://github.com/apache/apisix/pull/2935#issuecomment-742247728
> > > @Firstsawyou Could you paste some sample traffic split configurations
here to help us understand the schema better.
> >
> >
> > @tokers These are two cases, which will help you understand：
> > ### Grayscale Release
> > Traffic is split according to the weight value configured by upstreams
in the plugin (the rule of `match` is not configured, and `match` is passed by
default). The request traffic is divided into 4:2, 2/3 of the traffic reaches
the upstream of the `1981` port in the plugin, and 1/3 of the traffic reaches
the upstream of the default `1980` port on the route.
> > ```json
> > {
> > "weight": 2
> > }
> > ```
> >
> >
> > There is only a `weight` value in the plugin upstreams, which represents
the weight value of the upstream traffic arriving on the route.
> > ```shell
> > curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY:
edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
> > {
> > "uri": "/index.html",
> > "plugins": {
> > "traffic-split": {
> > "rules": [
> > {
> > "upstreams": [
> > {
> > "upstream": {
> > "name": "upstream_A",
> > "type": "roundrobin",
> > "nodes": {
> > "127.0.0.1:1981":10
> > },
> > "timeout": {
> > "connect": 15,
> > "send": 15,
> > "read": 15
> > }
> > },
> > "weight": 4
> > },
> > {
> > "weight": 2
> > }
> > ]
> > }
> > ]
> > }
> > },
> > "upstream": {
> > "type": "roundrobin",
> > "nodes": {
> > "127.0.0.1:1980": 1
> > }
> > }
> > }'
> > ```
> >
> >
> > ### Custom Release
> > Multiple matching rules can be set in `match` (multiple conditions in
`vars` are the relationship of `add`, and the relationship between multiple
`vars` rules is the relationship of `or`; as long as one of the vars rules
passes, it means `match` passed), only one is configured here, and the traffic
is divided into 4:2 according to the value of `weight`. Among them, only the
`weight` part represents the proportion of upstream on the route. When `match`
fails to match, all traffic will only hit upstream on the route.
> > ```shell
> > curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY:
edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
> > {
> > "uri": "/index.html",
> > "plugins": {
> > "traffic-split": {
> > "rules": [
> > {
> > "match": [
> > {
> > "vars": [
> > ["arg_name","==","jack"],
> > ["http_user-id",">","23"],
> > ["http_apisix-key","~~","[a-z]+"]
> > ]
> > }
> > ],
> > "upstreams": [
> > {
> > "upstream": {
> > "name": "upstream_A",
> > "type": "roundrobin",
> > "nodes": {
> > "127.0.0.1:1981":10
> > }
> > },
> > "weight": 4
> > },
> > {
> > "weight": 2
> > }
> > ]
> > }
> > ]
> > }
> > },
> > "upstream": {
> > "type": "roundrobin",
> > "nodes": {
> > "127.0.0.1:1980": 1
> > }
> > }
> > }'
> > ```
>
> I have several questions:
>
> 1. Why the upstream defined in traffic split has name?
> 2. The block which only contains weight is confused, the configuration
should be self-contained as soon as possible, you nedd some mark to tell the
admin that it points to the default upstream.
> 3. The upstream embedded inside traffic split brings some troubles such as
health check, people wishes unhealthy nodes should be excluded, which is not
implemented in your PR, a better way to achieve this is using upstream_id to
reference already defined upstreams.
> 4. the `upstreams` should highlight its function, i.e. weighted selection,
so maybe "weighted_upstreams" or "weighted_clusters" is more suitable, since we
will have label based selector in the future, we should distinguish them.
1. The name is to identify the upstream service name, usage scenario, etc.
2. I think it is not appropriate to add the default upstream configuration
of `route` to only include the `weight`, because the configuration is repeated,
and currently this plugin does not support some fields of the default upstream.
3. Yes, this is a version, we need to support it later.
4. I will update it later.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
