You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by GitBox <gi...@apache.org> on 2021/07/19 00:57:09 UTC

[GitHub] [apisix] spacewander commented on a change in pull request #4615: docs: improve/sync zh and en docs of the admin-api

spacewander commented on a change in pull request #4615:
URL: https://github.com/apache/apisix/pull/4615#discussion_r671927350



##########
File path: docs/en/latest/admin-api.md
##########
@@ -536,31 +536,31 @@ Return response from etcd currently.
 
 In addition to the basic complex equalization algorithm selection, APISIX's Upstream also supports logic for upstream passive health check and retry, see the table below.
 
-|Name            |Optional|Description|
-|----------------|--------|-----------|
-|type            |required|the balancer algorithm|
-|nodes           |required, can't be used with `service_name` |Hash table or array. If it is a hash table, the key of the internal element is the upstream machine address list, the format is `Address + (optional) Port`, where the address part can be IP or domain name, such as `192.168.1.100:80`, `foo.com:80`, etc. The value is the weight of node. If it is an array, each item is a hash table with key `host`/`weight` and optional `port`/`priority`. The `nodes` can be empty, which means it is a placeholder and will be filled later. Clients use such an upstream will get 502 response. |
-|service_name    |required, can't be used with `nodes` |the name of service used in the service discovery, see [discovery](discovery.md) for more details|
-|discovery_type  |required, if `service_name` is used | the type of service discovery, see [discovery](discovery.md) for more details|
-|hash_on         |optional|This option is only valid if the `type` is `chash`. Supported types `vars`(Nginx variables), `header`(custom header), `cookie`, `consumer`, the default value is `vars`.|
-|key             |optional|This option is only valid if the `type` is `chash`. Find the corresponding node `id` according to `hash_on` and `key`. When `hash_on` is set as `vars`, `key` is the required parameter, for now, it support nginx built-in variables like `uri, server_name, server_addr, request_uri, remote_port, remote_addr, query_string, host, hostname, arg_***`, `arg_***` is arguments in the request line, [Nginx variables list](http://nginx.org/en/docs/varindex.html). When `hash_on` is set as `header`, `key` is the required parameter, and `header name` is customized. When `hash_on` is set to `cookie`, `key` is the required parameter, and `cookie name` is customized. When `hash_on` is set to `consumer`, `key` does not need to be set. In this case, the `key` adopted by the hash algorithm is the `consumer_name` authenticated. If the specified `hash_on` and `key` can not fetch values, it will be fetch `remote_addr` by default.|
-|checks          |optional|Configure the parameters of the health check. For details, refer to [health-check](health-check.md).|
-|retries         |optional|Pass the request to the next upstream using the underlying Nginx retry mechanism, the retry mechanism is enabled by default and set the number of retries according to the number of available backend nodes. If `retries` option is explicitly set, it will override the default value. `0` means disable retry mechanism.|
-|retry_timeout   |optional|Configure a number to limit the amount of seconds that retries can be continued, and do not continue retries if the previous request and retry requests have taken too long. `0` means disable retry timeout mechanism.|
-|timeout         |optional| Set the timeout for connecting, sending and receiving messages. |
-|name            |optional|Identifies upstream names|
-|desc            |optional|upstream usage scenarios, and more.|
-|pass_host       |optional| `host` option when the request is sent to the upstream, can be one of [`pass`, `node`, `rewrite`], the default option is `pass`. `pass`: Pass the client's host transparently to the upstream; `node`: Use the host configured in the node of `upstream`; `rewrite`: Use the value of the configuration `upstream_host`.|
-|upstream_host   |optional|Specify the host of the upstream request. This option is only valid if the `pass_host` is `rewrite`.|
-|scheme          |optional |The scheme used when talk with the upstream. The value is one of ['http', 'https', 'grpc', 'grpcs'], default to 'http'.|
-|labels          |optional |Key/value pairs to specify attributes|{"version":"v2","build":"16","env":"production"}|
-|create_time     |optional| epoch timestamp in second, like `1602883670`, will be created automatically if missing|
-|update_time     |optional| epoch timestamp in second, like `1602883670`, will be created automatically if missing|
-|tls.client_cert |optional| Set the client certificate when connecting to TLS upstream, see below for more details|
-|tls.client_key  |optional| Set the client priviate key when connecting to TLS upstream, see below for more details|
-|keepalive_pool.size  |optional| Set `keepalive` directive dynamically, see below for more details|
-|keepalive_pool.idle_timeout  |optional| Set `keepalive_timeout` directive dynamically, see below for more details|
-|keepalive_pool.requests  |optional| Set `keepalive_requests` directive dynamically, see below for more details|
+|Name            |Optional|Description|Example|
+|----------------|--------|-----------|-----------|
+|type            |required|the balancer algorithm||
+|nodes           |required, can't be used with `service_name` |Hash table or array. If it is a hash table, the key of the internal element is the upstream machine address list, the format is `Address + (optional) Port`, where the address part can be IP or domain name, such as `192.168.1.100:80`, `foo.com:80`, etc. The value is the weight of node. If it is an array, each item is a hash table with key `host`/`weight` and optional `port`/`priority`. The `nodes` can be empty, which means it is a placeholder and will be filled later. Clients use such an upstream will get 502 response. |`192.168.1.100:80`|
+|service_name    |required, can't be used with `nodes` |the name of service used in the service discovery, see [discovery](discovery.md) for more details|`a-bootiful-client`|
+|discovery_type  |required, if `service_name` is used | the type of service discovery, see [discovery](discovery.md) for more details|`eureka`|
+|hash_on         |optional|This option is only valid if the `type` is `chash`. Supported types `vars`(Nginx variables), `header`(custom header), `cookie`, `consumer`, the default value is `vars`.||
+|key             |optional|This option is only valid if the `type` is `chash`. Find the corresponding node `id` according to `hash_on` and `key`. When `hash_on` is set as `vars`, `key` is the required parameter, for now, it support nginx built-in variables like `uri, server_name, server_addr, request_uri, remote_port, remote_addr, query_string, host, hostname, arg_***`, `arg_***` is arguments in the request line, [Nginx variables list](http://nginx.org/en/docs/varindex.html). When `hash_on` is set as `header`, `key` is the required parameter, and `header name` is customized. When `hash_on` is set to `cookie`, `key` is the required parameter, and `cookie name` is customized. When `hash_on` is set to `consumer`, `key` does not need to be set. In this case, the `key` adopted by the hash algorithm is the `consumer_name` authenticated. If the specified `hash_on` and `key` can not fetch values, it will be fetch `remote_addr` by default.||
+|checks          |optional|Configure the parameters of the health check. For details, refer to [health-check](health-check.md).||
+|retries         |optional|Pass the request to the next upstream using the underlying Nginx retry mechanism, the retry mechanism is enabled by default and set the number of retries according to the number of available backend nodes. If `retries` option is explicitly set, it will override the default value. `0` means disable retry mechanism.||
+|retry_timeout   |optional|Configure a number to limit the amount of seconds that retries can be continued, and do not continue retries if the previous request and retry requests have taken too long. `0` means disable retry timeout mechanism.||
+|timeout         |optional| Set the timeout for connecting, sending and receiving messages. ||
+|name            |optional|Identifies upstream names||
+|desc            |optional|upstream usage scenarios, and more.||
+|pass_host       |optional| `host` option when the request is sent to the upstream, can be one of [`pass`, `node`, `rewrite`], the default option is `pass`. `pass`: Pass the client's host transparently to the upstream; `node`: Use the host configured in the node of `upstream`; `rewrite`: Use the value of the configuration `upstream_host`.||
+|upstream_host   |optional|Specify the host of the upstream request. This option is only valid if the `pass_host` is `rewrite`.||
+|scheme          |optional |The scheme used when talk with the upstream. The value is one of ['http', 'https', 'grpc', 'grpcs'], default to 'http'.||
+|labels          |optional |Key/value pairs to specify attributes|{"version":"v2","build":"16","env":"production"}|{"version":"v2","build":"16","env":"production"}|

Review comment:
       This row already has an example




-- 
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.

To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org