docs: removing links to v1 docs (#4743)

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

Hide file tree

Showing 36 changed files with 15 additions and 54 deletions.
diff --git a/docs/root/about_docs.rst b/docs/root/about_docs.rst
@@ -7,14 +7,12 @@ The Envoy documentation is composed of a few major sections:
   architecture overview, how it is typically deployed, etc.
 * :ref:`Getting Started <start>`: Quickly get started with Envoy using Docker.
 * :ref:`Installation <install>`: How to build/install Envoy using Docker.
-* :ref:`Configuration <config>`: Detailed configuration instructions common to both the legacy v1
-  API and the new v2 API. Where relevant, the configuration guide also contains information on
-  statistics, runtime configuration, and APIs.
+* :ref:`Configuration <config>`: Detailed configuration instructions for Envoy's v2 API.
+  Where relevant, the configuration guide also contains information on statistics, runtime
+  configuration, and APIs.
 * :ref:`Operations <operations>`: General information on how to operate Envoy including the command
   line interface, hot restart wrapper, administration interface, a general statistics overview,
   etc.
 * :ref:`Extending Envoy <extending>`: Information on how to write custom filters for Envoy.
-* :ref:`v1 API reference <envoy_v1_api_reference>`: Configuration details specific to the legacy
-  v1 API.
 * :ref:`v2 API reference <envoy_api_reference>`: Configuration details specific to the new v2 API.
 * :ref:`Envoy FAQ <faq_overview>`: Have questions? We have answers. Hopefully.
diff --git a/docs/root/configuration/access_log.rst b/docs/root/configuration/access_log.rst
@@ -9,7 +9,6 @@ Configuration
 Access logs are configured as part of the :ref:`HTTP connection manager config
 <config_http_conn_man>` or :ref:`TCP Proxy <config_network_filters_tcp_proxy>`.
 
-* :ref:`v1 API reference <config_access_log_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.filter.accesslog.v2.AccessLog>`
 
 .. _config_access_log_format:

diff --git a/docs/root/configuration/cluster_manager/cds.rst b/docs/root/configuration/cluster_manager/cds.rst
@@ -12,7 +12,6 @@ clusters depending on what is required.
   Any clusters that are statically defined within the Envoy configuration cannot be modified or
   removed via the CDS API.
 
-* :ref:`v1 CDS API <config_cluster_manager_cds_v1>`
 * :ref:`v2 CDS API <v2_grpc_streaming_endpoints>`
 
 Statistics
@@ -30,4 +29,4 @@ CDS has a statistics tree rooted at *cluster_manager.cds.* with the following st
   update_failure, Counter, Total API fetches that failed because of network errors
   update_rejected, Counter, Total API fetches that failed because of schema/validation errors
   version, Gauge, Hash of the contents from the last successful API fetch
-  control_plane.connected_state, Gauge, A boolan (1 for connected and 0 for disconnected) that indicates the current connection state with management server
+  control_plane.connected_state, Gauge, A boolan (1 for connected and 0 for disconnected) that indicates the current connection state with management server
diff --git a/docs/root/configuration/cluster_manager/cluster_circuit_breakers.rst b/docs/root/configuration/cluster_manager/cluster_circuit_breakers.rst
@@ -4,7 +4,6 @@ Circuit breaking
 ================
 
 * Circuit Breaking :ref:`architecture overview <arch_overview_circuit_break>`.
-* :ref:`v1 API documentation <config_cluster_manager_cluster_circuit_breakers_v1>`.
 * :ref:`v2 API documentation <envoy_api_msg_cluster.CircuitBreakers>`.
 
 Runtime

diff --git a/docs/root/configuration/cluster_manager/cluster_hc.rst b/docs/root/configuration/cluster_manager/cluster_hc.rst
@@ -6,7 +6,6 @@ Health checking
 * Health checking :ref:`architecture overview <arch_overview_health_checking>`.
 * If health checking is configured for a cluster, additional statistics are emitted. They are
   documented :ref:`here <config_cluster_manager_cluster_stats>`.
-* :ref:`v1 API documentation <config_cluster_manager_cluster_hc_v1>`.
 * :ref:`v2 API documentation <envoy_api_msg_core.HealthCheck>`.
 
 .. _config_cluster_manager_cluster_hc_tcp_health_checking:

diff --git a/docs/root/configuration/cluster_manager/cluster_manager.rst b/docs/root/configuration/cluster_manager/cluster_manager.rst
@@ -13,5 +13,4 @@ Cluster manager
   cluster_circuit_breakers
 
 * Cluster manager :ref:`architecture overview <arch_overview_cluster_manager>`
-* :ref:`v1 API reference <config_cluster_manager_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.bootstrap.v2.ClusterManager>`
diff --git a/docs/root/configuration/http_conn_man/headers.rst b/docs/root/configuration/http_conn_man/headers.rst
@@ -357,7 +357,6 @@ is out of scope for this documentation. If *x-request-id* is propagated across a
 following features are available:
 
 * Stable :ref:`access logging <config_access_log>` via the
-  :ref:`v1 API runtime filter<config_http_con_manager_access_log_filters_runtime_v1>` or the
   :ref:`v2 API runtime filter<envoy_api_field_config.filter.accesslog.v2.AccessLogFilter.runtime_filter>`.
 * Stable tracing when performing random sampling via the :ref:`tracing.random_sampling
   <config_http_conn_man_runtime_random_sampling>` runtime setting or via forced tracing using the
@@ -435,9 +434,8 @@ Custom request/response headers
 -------------------------------
 
 Custom request/response headers can be added to a request/response at the weighted cluster,
-route, virtual host, and/or global route configuration level. See the relevant :ref:`v1
-<config_http_conn_man_route_table>` and :ref:`v2 <envoy_api_msg_RouteConfiguration>` API
-documentation.
+route, virtual host, and/or global route configuration level. See the
+:ref:`v2 <envoy_api_msg_RouteConfiguration>` API documentation.
 
 No *:*-prefixed pseudo-header may be modified via this mechanism. The *:path*
 and *:authority* headers may instead be modified via mechanisms such as

diff --git a/docs/root/configuration/http_conn_man/http_conn_man.rst b/docs/root/configuration/http_conn_man/http_conn_man.rst
@@ -5,7 +5,6 @@ HTTP connection manager
 
 * HTTP connection manager :ref:`architecture overview <arch_overview_http_conn_man>`
 * HTTP protocols :ref:`architecture overview <arch_overview_http_protocols>`
-* :ref:`v1 API reference <config_network_filters_http_conn_man_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.filter.network.http_connection_manager.v2.HttpConnectionManager>`
 
 .. toctree::

diff --git a/docs/root/configuration/http_conn_man/rds.rst b/docs/root/configuration/http_conn_man/rds.rst
@@ -9,7 +9,6 @@ HTTP header modifications, virtual hosts, and the individual route entries conta
 virtual host. Each :ref:`HTTP connection manager filter <config_http_conn_man>` can independently
 fetch its own route configuration via the API.
 
-* :ref:`v1 API reference <config_http_conn_man_rds_v1>`
 * :ref:`v2 API reference <v2_grpc_streaming_endpoints>`
 
 Statistics

diff --git a/docs/root/configuration/http_filters/buffer_filter.rst b/docs/root/configuration/http_filters/buffer_filter.rst
@@ -7,7 +7,6 @@ The buffer filter is used to stop filter iteration and wait for a fully buffered
 This is useful in different situations including protecting some applications from having to deal
 with partial requests and high network latency.
 
-* :ref:`v1 API reference <config_http_filters_buffer_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.filter.http.buffer.v2.Buffer>`
 
 Per-Route Configuration

diff --git a/docs/root/configuration/http_filters/cors_filter.rst b/docs/root/configuration/http_filters/cors_filter.rst
@@ -8,5 +8,4 @@ For the meaning of the headers please refer to the pages below.
 
 - https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
 - https://www.w3.org/TR/cors/
-- :ref:`v1 API reference <config_http_conn_man_route_table_cors>`
 - :ref:`v2 API reference <envoy_api_msg_route.CorsPolicy>`
diff --git a/docs/root/configuration/http_filters/dynamodb_filter.rst b/docs/root/configuration/http_filters/dynamodb_filter.rst
@@ -4,7 +4,6 @@ DynamoDB
 ========
 
 * DynamoDB :ref:`architecture overview <arch_overview_dynamo>`
-* :ref:`v1 API reference <config_http_filters_dynamo_v1>`
 * :ref:`v2 API reference <envoy_api_field_config.filter.network.http_connection_manager.v2.HttpFilter.name>`
 
 Statistics

diff --git a/docs/root/configuration/http_filters/fault_filter.rst b/docs/root/configuration/http_filters/fault_filter.rst
@@ -33,7 +33,6 @@ Configuration
   The fault injection filter must be inserted before any other filter,
   including the router filter.
 
-* :ref:`v1 API reference <config_http_filters_fault_injection_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.filter.http.fault.v2.HTTPFault>`
 
 Runtime

diff --git a/docs/root/configuration/http_filters/grpc_http1_bridge_filter.rst b/docs/root/configuration/http_filters/grpc_http1_bridge_filter.rst
@@ -4,7 +4,6 @@ gRPC HTTP/1.1 bridge
 ====================
 
 * gRPC :ref:`architecture overview <arch_overview_grpc>`
-* :ref:`v1 API reference <config_http_filters_grpc_bridge_v1>`
 * :ref:`v2 API reference <envoy_api_field_config.filter.network.http_connection_manager.v2.HttpFilter.name>`
 
 This is a simple filter which enables the bridging of an HTTP/1.1 client which does not support

diff --git a/docs/root/configuration/http_filters/grpc_json_transcoder_filter.rst b/docs/root/configuration/http_filters/grpc_json_transcoder_filter.rst
@@ -4,7 +4,6 @@ gRPC-JSON transcoder
 ====================
 
 * gRPC :ref:`architecture overview <arch_overview_grpc>`
-* :ref:`v1 API reference <config_http_filters_grpc_json_transcoder_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.filter.http.transcoder.v2.GrpcJsonTranscoder>`
 
 This is a filter which allows a RESTful JSON API client to send requests to Envoy over HTTP

diff --git a/docs/root/configuration/http_filters/grpc_web_filter.rst b/docs/root/configuration/http_filters/grpc_web_filter.rst
@@ -4,7 +4,6 @@ gRPC-Web
 ========
 
 * gRPC :ref:`architecture overview <arch_overview_grpc>`
-* :ref:`v1 API reference <config_http_filters_grpc_web_v1>`
 * :ref:`v2 API reference <envoy_api_field_config.filter.network.http_connection_manager.v2.HttpFilter.name>`
 
 This is a filter which enables the bridging of a gRPC-Web client to a compliant gRPC server by

diff --git a/docs/root/configuration/http_filters/health_check_filter.rst b/docs/root/configuration/http_filters/health_check_filter.rst
@@ -4,7 +4,6 @@ Health check
 ============
 
 * Health check filter :ref:`architecture overview <arch_overview_health_checking_filter>`
-* :ref:`v1 API reference <config_http_filters_health_check_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.filter.http.health_check.v2.HealthCheck>`
 
 .. note::

diff --git a/docs/root/configuration/http_filters/lua_filter.rst b/docs/root/configuration/http_filters/lua_filter.rst
@@ -54,7 +54,6 @@ API.
 Configuration
 -------------
 
-* :ref:`v1 API reference <config_http_filters_lua_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.filter.http.lua.v2.Lua>`
 
 Script examples

diff --git a/docs/root/configuration/http_filters/rate_limit_filter.rst b/docs/root/configuration/http_filters/rate_limit_filter.rst
@@ -4,7 +4,6 @@ Rate limit
 ==========
 
 * Global rate limiting :ref:`architecture overview <arch_overview_rate_limit>`
-* :ref:`v1 API reference <config_http_filters_rate_limit_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.filter.http.rate_limit.v2.RateLimit>`
 
 The HTTP rate limit filter will call the rate limit service when the request's route or virtual host

diff --git a/docs/root/configuration/http_filters/router_filter.rst b/docs/root/configuration/http_filters/router_filter.rst
@@ -8,7 +8,6 @@ that Envoy is deployed for. The filter's main job is to follow the instructions
 configured :ref:`route table <envoy_api_msg_RouteConfiguration>`. In addition to forwarding and
 redirection, the filter also handles retry, statistics, etc.
 
-* :ref:`v1 API reference <config_http_filters_router_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.filter.http.router.v2.Router>`
 
 .. _config_http_filters_router_headers_consumed:

diff --git a/docs/root/configuration/http_filters/squash_filter.rst b/docs/root/configuration/http_filters/squash_filter.rst
@@ -20,7 +20,6 @@ request, before the request arrive to the application code, without any changes
 Configuration
 -------------
 
-* :ref:`v1 API reference <config_http_filters_squash_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.filter.http.squash.v2.Squash>`
 
 How it works

diff --git a/docs/root/configuration/listeners/lds.rst b/docs/root/configuration/listeners/lds.rst
@@ -31,7 +31,6 @@ The semantics of listener updates are as follows:
 Configuration
 -------------
 
-* :ref:`v1 LDS API <config_listeners_lds_v1>`
 * :ref:`v2 LDS API <v2_grpc_streaming_endpoints>`
 
 Statistics
@@ -49,4 +48,4 @@ LDS has a statistics tree rooted at *listener_manager.lds.* with the following s
   update_failure, Counter, Total API fetches that failed because of network errors
   update_rejected, Counter, Total API fetches that failed because of schema/validation errors
   version, Gauge, Hash of the contents from the last successful API fetch
-  control_plane.connected_state, Gauge, A boolan (1 for connected and 0 for disconnected) that indicates the current connection state with management server
+  control_plane.connected_state, Gauge, A boolan (1 for connected and 0 for disconnected) that indicates the current connection state with management server
diff --git a/docs/root/configuration/listeners/listeners.rst b/docs/root/configuration/listeners/listeners.rst
@@ -6,7 +6,6 @@ Listeners
 The top level Envoy configuration contains a list of :ref:`listeners <arch_overview_listeners>`.
 Each individual listener configuration has the following format:
 
-* :ref:`v1 API reference <config_listeners_v1>`
 * :ref:`v2 API reference <envoy_api_msg_Listener>`
 
 .. toctree::

diff --git a/docs/root/configuration/network_filters/client_ssl_auth_filter.rst b/docs/root/configuration/network_filters/client_ssl_auth_filter.rst
@@ -4,7 +4,6 @@ Client TLS authentication
 =========================
 
 * Client TLS authentication filter :ref:`architecture overview <arch_overview_ssl_auth_filter>`
-* :ref:`v1 API reference <config_network_filters_client_ssl_auth_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.filter.network.client_ssl_auth.v2.ClientSslAuth>`
 
 .. _config_network_filters_client_ssl_auth_stats:

diff --git a/docs/root/configuration/network_filters/echo_filter.rst b/docs/root/configuration/network_filters/echo_filter.rst
@@ -6,5 +6,4 @@ Echo
 The echo is a trivial network filter mainly meant to demonstrate the network filter API. If
 installed it will echo (write) all received data back to the connected downstream client.
 
-* :ref:`v1 API reference <config_network_filters_echo_v1>`
 * :ref:`v2 API reference <envoy_api_field_listener.Filter.name>`
diff --git a/docs/root/configuration/network_filters/mongo_proxy_filter.rst b/docs/root/configuration/network_filters/mongo_proxy_filter.rst
@@ -4,15 +4,14 @@ Mongo proxy
 ===========
 
 - MongoDB :ref:`architecture overview <arch_overview_mongo>`
-- :ref:`v1 API reference <config_network_filters_mongo_proxy_v1>`
 - :ref:`v2 API reference <envoy_api_msg_config.filter.network.mongo_proxy.v2.MongoProxy>`
 
 .. _config_network_filters_mongo_proxy_fault_injection:
 
 Fault injection
 ---------------
 
-The Mongo proxy filter supports fault injection. See the v1 and v2 API reference for how to
+The Mongo proxy filter supports fault injection. See the v2 API reference for how to
 configure.
 
 .. _config_network_filters_mongo_proxy_stats:

diff --git a/docs/root/configuration/network_filters/rate_limit_filter.rst b/docs/root/configuration/network_filters/rate_limit_filter.rst
@@ -4,7 +4,6 @@ Rate limit
 ==========
 
 * Global rate limiting :ref:`architecture overview <arch_overview_rate_limit>`
-* :ref:`v1 API reference <config_network_filters_rate_limit_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.filter.network.rate_limit.v2.RateLimit>`
 
 .. _config_network_filters_rate_limit_stats:

diff --git a/docs/root/configuration/network_filters/redis_proxy_filter.rst b/docs/root/configuration/network_filters/redis_proxy_filter.rst
@@ -4,7 +4,6 @@ Redis proxy
 ===========
 
 * Redis :ref:`architecture overview <arch_overview_redis>`
-* :ref:`v1 API reference <config_network_filters_redis_proxy_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.filter.network.redis_proxy.v2.RedisProxy>`
 
 .. _config_network_filters_redis_proxy_stats:

diff --git a/docs/root/configuration/network_filters/tcp_proxy_filter.rst b/docs/root/configuration/network_filters/tcp_proxy_filter.rst
@@ -4,7 +4,6 @@ TCP proxy
 =========
 
 * TCP proxy :ref:`architecture overview <arch_overview_tcp_proxy>`
-* :ref:`v1 API reference <config_network_filters_tcp_proxy_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.filter.network.tcp_proxy.v2.TcpProxy>`
 
 .. _config_network_filters_tcp_proxy_dynamic_cluster:

diff --git a/docs/root/configuration/overview/v1_overview.rst b/docs/root/configuration/overview/v1_overview.rst
@@ -5,8 +5,8 @@ Overview (v1 API)
 
 .. attention::
 
-  The v1 configuration/API is now considered legacy and the `deprecation schedule <https://groups.google.com/forum/#!topic/envoy-announce/Lb1QZcSclGQ>`_
-  has been announced. Please upgrade and use the :ref:`v2 configuration/API <config_overview_v2>`.
+  The v1 configuration/API is unsupported.
+  Please upgrade and use the :ref:`v2 configuration/API <config_overview_v2>`.
 
 The Envoy configuration format is written in JSON and is validated against a JSON schema. The
 schema can be found in :repo:`source/common/json/config_schemas.cc`. The main configuration for the

diff --git a/docs/root/configuration/overview/v2_overview.rst b/docs/root/configuration/overview/v2_overview.rst
@@ -6,8 +6,7 @@ Overview (v2 API)
 The Envoy v2 APIs are defined as `proto3
 <https://developers.google.com/protocol-buffers/docs/proto3>`_ `Protocol Buffers
 <https://developers.google.com/protocol-buffers/>`_ in the `data plane API
-repository <https://github.com/envoyproxy/data-plane-api/tree/master/envoy/api>`_. They evolve the
-existing :ref:`v1 APIs and concepts <config_overview_v1>` to support:
+repository <https://github.com/envoyproxy/data-plane-api/tree/master/envoy/api>`_. They support
 
 * Streaming delivery of `xDS <https://github.com/envoyproxy/data-plane-api/blob/master/XDS_PROTOCOL.md>`_
   API updates via gRPC. This reduces resource requirements and can lower the update latency.
@@ -31,9 +30,8 @@ Bootstrap configuration
 
 To use the v2 API, it's necessary to supply a bootstrap configuration file. This
 provides static server configuration and configures Envoy to access :ref:`dynamic
-configuration if needed <arch_overview_dynamic_config>`. As with the v1
-JSON/YAML configuration, this is supplied on the command-line via the :option:`-c`
-flag, i.e.:
+configuration if needed <arch_overview_dynamic_config>`. This is supplied on the command-line via
+the :option:`-c` flag, i.e.:
 
 .. code-block:: console
 
@@ -323,7 +321,7 @@ Upgrading from v1 configuration
 -------------------------------
 
 While new v2 bootstrap JSON/YAML can be written, it might be expedient to upgrade an existing
-:ref:`v1 JSON/YAML configuration <config_overview_v1>` to v2. To do this (in an Envoy source tree),
+v1 JSON/YAML configuration to v2. To do this (in an Envoy source tree),
 you can run:
 
 .. code-block:: console

diff --git a/docs/root/configuration/rate_limit.rst b/docs/root/configuration/rate_limit.rst
@@ -7,7 +7,6 @@ The :ref:`rate limit service <arch_overview_rate_limit>` configuration specifies
 limit service Envoy should talk to when it needs to make global rate limit decisions. If no rate
 limit service is configured, a "null" service will be used which will always return OK if called.
 
-* :ref:`v1 API reference <config_rate_limit_service_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.ratelimit.v2.RateLimitServiceConfig>`
 
 gRPC service IDL

diff --git a/docs/root/configuration/runtime.rst b/docs/root/configuration/runtime.rst
@@ -17,7 +17,6 @@ built into the code, except for any values added via `/runtime_modify`.
   secured <operations_admin_interface_security>`.
 
 
-* :ref:`v1 API reference <config_runtime_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.bootstrap.v2.Runtime>`
 
 File system layout

diff --git a/docs/root/intro/arch_overview/statistics.rst b/docs/root/intro/arch_overview/statistics.rst
@@ -18,8 +18,7 @@ can be used to get a detailed picture of that particular network hop. Statistics
 mesh give a very detailed picture of each hop and overall network health. The statistics emitted are
 documented in detail in the operations guide.
 
-In the v1 API, Envoy only supports statsd as the statistics output format. Both TCP and UDP statsd
-are supported. As of the v2 API, Envoy has the ability to support custom, pluggable sinks. :ref:`A
+As of the v2 API, Envoy has the ability to support custom, pluggable sinks. :ref:`A
 few standard sink implementations<envoy_api_msg_config.metrics.v2.StatsSink>` are included in Envoy.
 Some sinks also support emitting statistics with tags/dimensions.
 
@@ -38,5 +37,4 @@ Internally, counters and gauges are batched and periodically flushed to improve
 Histograms are written as they are received. Note: what were previously referred to as timers have
 become histograms as the only difference between the two representations was the units.
 
-* :ref:`v1 API reference <config_overview_v1>`.
 * :ref:`v2 API reference <envoy_api_field_config.bootstrap.v2.Bootstrap.stats_sinks>`.
diff --git a/docs/root/intro/arch_overview/tracing.rst b/docs/root/intro/arch_overview/tracing.rst
@@ -96,7 +96,6 @@ multiple spans are stitched together using common information such as the global
 request ID :ref:`config_http_conn_man_headers_x-request-id` (LightStep) or
 the trace ID configuration (Zipkin). See
 
-* :ref:`v1 API reference <config_tracing_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.trace.v2.Tracing>`
 
 for more information on how to setup tracing in Envoy.
diff --git a/docs/root/operations/admin.rst b/docs/root/operations/admin.rst
@@ -6,7 +6,6 @@ Administration interface
 Envoy exposes a local administration interface that can be used to query and
 modify different aspects of the server:
 
-* :ref:`v1 API reference <config_admin_v1>`
 * :ref:`v2 API reference <envoy_api_msg_config.bootstrap.v2.Admin>`
 
 .. _operations_admin_interface_security: