docs: updating docs with explicit v1 callouts (#4728)

Part of removing v1 docs. Risk Level: low (risk of bad docs) Testing: n/a Docs Changes: yep Release Notes: nope Part of #4617 Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
envoyproxy · Oct 16, 2018 · f1b4847 · f1b4847
1 parent 4f94a52
commit f1b4847
Show file tree

Hide file tree

Showing 4 changed files with 60 additions and 138 deletions.
diff --git a/docs/root/configuration/cluster_manager/cluster_hc.rst b/docs/root/configuration/cluster_manager/cluster_hc.rst
@@ -14,54 +14,20 @@ Health checking
 TCP health checking
 -------------------
 
-.. attention::
+The type of matching performed is the following:
 
-  This section is written for the v1 API but the concepts also apply to the v2 API. It will be
-  rewritten to target the v2 API in a future release.
+.. code-block:: yaml
 
-The type of matching performed is the following (this is the MongoDB health check request and
-response):
 
-.. code-block:: json
+  tcp_health_check:
+      send: {text: '0101'}
+      receive: [{text: '02'}, {text: '03'}]
 
-  {
-    "send": [
-      {"binary": "39000000"},
-      {"binary": "EEEEEEEE"},
-      {"binary": "00000000"},
-      {"binary": "d4070000"},
-      {"binary": "00000000"},
-      {"binary": "746573742e"},
-      {"binary": "24636d6400"},
-      {"binary": "00000000"},
-      {"binary": "FFFFFFFF"},
-      {"binary": "13000000"},
-      {"binary": "01"},
-      {"binary": "70696e6700"},
-      {"binary": "000000000000f03f"},
-      {"binary": "00"}
-     ],
-     "receive": [
-      {"binary": "EEEEEEEE"},
-      {"binary": "01000000"},
-      {"binary": "00000000"},
-      {"binary": "0000000000000000"},
-      {"binary": "00000000"},
-      {"binary": "11000000"},
-      {"binary": "01"},
-      {"binary": "6f6b"},
-      {"binary": "00000000000000f03f"},
-      {"binary": "00"}
-     ]
- }
+During each health check cycle, all of the "send" bytes are sent to the target server.
 
-During each health check cycle, all of the "send" bytes are sent to the target server. Each
-binary block can be of arbitrary length and is just concatenated together when sent. (Separating
-into multiple blocks can be useful for readability).
-
-When checking the response, "fuzzy" matching is performed such that each binary block must be found,
+When checking the response, "fuzzy" matching is performed such that each block must be found,
 and in the order specified, but not necessarily contiguous. Thus, in the example above,
-"FFFFFFFF" could be inserted in the response between "EEEEEEEE" and "01000000" and the check
+"04" could be inserted in the response between "02" and "03" and the check
 would still pass. This is done to support protocols that insert non-deterministic data, such as
 time, into the response.
 

diff --git a/docs/root/configuration/http_conn_man/route_matching.rst b/docs/root/configuration/http_conn_man/route_matching.rst
@@ -3,11 +3,6 @@
 Route matching
 ==============
 
-.. attention::
-
-  This section is written for the v1 API but the concepts also apply to the v2 API. It will be
-  rewritten to target the v2 API in a future release.
-
 When Envoy matches a route, it uses the following procedure:
 
 #. The HTTP request's *host* or *:authority* header is matched to a :ref:`virtual host

diff --git a/docs/root/configuration/http_conn_man/traffic_splitting.rst b/docs/root/configuration/http_conn_man/traffic_splitting.rst
@@ -3,11 +3,6 @@
 Traffic Shifting/Splitting
 ===========================================
 
-.. attention::
-
-  This section is written for the v1 API but the concepts also apply to the v2 API. It will be
-  rewritten to target the v2 API in a future release.
-
 .. contents::
   :local:
 
@@ -31,41 +26,36 @@ section describes this scenario in more detail.
 Traffic shifting between two upstreams
 --------------------------------------
 
-The :ref:`runtime <envoy_api_field_route.RouteMatch.runtime>` object
+The :ref:`runtime <envoy_api_field_route.RouteMatch.runtime_fraction>` object
 in the route configuration determines the probability of selecting a
-particular route (and hence its cluster). By using the runtime
+particular route (and hence its cluster). By using the *runtime_fraction*
 configuration, traffic to a particular route in a virtual host can be
 gradually shifted from one cluster to another. Consider the following
 example configuration, where two versions ``helloworld_v1`` and
 ``helloworld_v2`` of a service named ``helloworld`` are declared in the
 envoy configuration file.
 
-.. code-block:: json
-
-    {
-      "route_config": {
-        "virtual_hosts": [
-          {
-            "name": "helloworld",
-            "domains": ["*"],
-            "routes": [
-              {
-                "prefix": "/",
-                "cluster": "helloworld_v1",
-                "runtime": {
-                  "key": "routing.traffic_shift.helloworld",
-                  "default": 50
-                }
-              },
-              {
-                "prefix": "/",
-                "cluster": "helloworld_v2",
-              }
-            ]
-          }
-        ]
-      }
-    }
+.. code-block:: yaml
+
+  virtual_hosts:
+     - name: www2
+       domains:
+       - '*'
+       routes:
+         - match:
+             prefix: /
+             runtime_fraction:
+               default_value:
+                 numerator: 50
+                 denominator: HUNDRED
+               runtime_key: routing.traffic_shift.helloworld
+           route:
+             cluster: helloworld_v1
+         - match:
+             prefix: /
+           route:
+             cluster: helloworld_v2
+
 
 Envoy matches routes with a :ref:`first match <config_http_conn_man_route_table_route_matching>` policy.
 If the route has a runtime object, the request will be additionally matched based on the runtime
@@ -109,31 +99,24 @@ configuration block in a route can be used to specify multiple upstream clusters
 along with weights that indicate the **percentage** of traffic to be sent
 to each upstream cluster.
 
-.. code-block:: json
-
-    {
-      "route_config": {
-        "virtual_hosts": [
-          {
-            "name": "helloworld",
-            "domains": ["*"],
-            "routes": [
-              {
-                "prefix": "/",
-                "weighted_clusters": {
-                  "runtime_key_prefix" : "routing.traffic_split.helloworld",
-                  "clusters" : [
-                    { "name" : "helloworld_v1", "weight" : 33 },
-                    { "name" : "helloworld_v2", "weight" : 33 },
-                    { "name" : "helloworld_v3", "weight" : 34 }
-                  ]
-                }
-              }
-            ]
-          }
-        ]
-      }
-    }
+.. code-block:: yaml
+
+  virtual_hosts:
+     - name: www2
+       domains:
+       - '*'
+       routes:
+         - match: { prefix: / }
+           route:
+             weighted_clusters:
+               clusters:
+                 - name: helloworld_v1
+                   weight: 33
+                 - name: helloworld_v2
+                   weight: 33
+                 - name: helloworld_v3
+                   weight: 34
+
 
 By default, the weights must sum to exactly 100. In the V2 API, the
 :ref:`total weight <envoy_api_field_route.WeightedCluster.total_weight>` defaults to 100, but can

diff --git a/docs/root/configuration/http_filters/rate_limit_filter.rst b/docs/root/configuration/http_filters/rate_limit_filter.rst
@@ -24,11 +24,6 @@ set to true, a 500 response is returned.
 Composing Actions
 -----------------
 
-.. attention::
-
-  This section is written for the v1 API but the concepts also apply to the v2 API. It will be
-  rewritten to target the v2 API in a future release.
-
 Each :ref:`rate limit action <envoy_api_msg_route.RateLimit>` on the route or
 virtual host populates a descriptor entry. A vector of descriptor entries compose a descriptor. To
 create more complex rate limit descriptors, actions can be composed in any order. The descriptor
@@ -46,19 +41,11 @@ For example, to generate the following descriptor:
 
 The configuration would be:
 
-.. code-block:: json
+.. code-block:: yaml
 
-  {
-    "actions" : [
-    {
-      "type" : "generic_key",
-      "descriptor_value" : "some_value"
-    },
-    {
-      "type" : "source_cluster"
-    }
-    ]
-  }
+  actions:
+      - {source_cluster: {}}
+      - {generic_key: {descriptor_value: some_value}}
 
 Example 2
 ^^^^^^^^^
@@ -68,22 +55,13 @@ the configuration.
 
 For the following configuration:
 
-.. code-block:: json
-
-  {
-    "actions" : [
-    {
-      "type" : "generic_key",
-      "descriptor_value" : "some_value"
-    },
-    {
-      "type" : "remote_address"
-    },
-    {
-      "type" : "souce_cluster"
-    }
-    ]
-  }
+.. code-block:: yaml
+
+  actions:
+      - {source_cluster: {}}
+      - {remote_address: {}}
+      - {generic_key: {descriptor_value: some_value}}
+
 
 If a request did not set :ref:`x-forwarded-for<config_http_conn_man_headers_x-forwarded-for>`,
 no descriptor is generated.