From 1cbc7cc27468a18f14da8c3607c6a2047837af0b Mon Sep 17 00:00:00 2001
From: Anthony Romano <anthony.romano@coreos.com>
Date: Thu, 1 Jun 2017 14:45:51 -0700
Subject: [PATCH] op-guide: document configuration flags for gateway

---
 Documentation/op-guide/gateway.md | 43 +++++++++++++++++++++++++++++--
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/Documentation/op-guide/gateway.md b/Documentation/op-guide/gateway.md
index a7cd1be6f6a..10fe5d0c3b1 100644
--- a/Documentation/op-guide/gateway.md
+++ b/Documentation/op-guide/gateway.md
@@ -10,8 +10,7 @@ The gateway supports multiple etcd server endpoints and works on a simple round-
 
 Every application that accesses etcd must first have the address of an etcd cluster client endpoint. If multiple applications on the same server access the same etcd cluster, every application still needs to know the advertised client endpoints of the etcd cluster. If the etcd cluster is reconfigured to have different endpoints, every application may also need to update its endpoint list. This wide-scale reconfiguration is both tedious and error prone.
 
-etcd gateway solves this problem by serving as a stable local endpoint. A typical etcd gateway configuration has 
-each machine running a gateway listening on a local address and every etcd application connecting to its local gateway. The upshot is only the gateway needs to update its endpoints instead of updating each and every application.
+etcd gateway solves this problem by serving as a stable local endpoint. A typical etcd gateway configuration has each machine running a gateway listening on a local address and every etcd application connecting to its local gateway. The upshot is only the gateway needs to update its endpoints instead of updating each and every application.
 
 In summary, to automatically propagate cluster endpoint changes, the etcd gateway runs on every machine serving multiple applications accessing the same etcd cluster.
 
@@ -64,3 +63,43 @@ Start the etcd gateway to fetch the endpoints from the DNS SRV entries with the
 $ etcd gateway --discovery-srv=example.com
 2016-08-16 11:21:18.867350 I | tcpproxy: ready to proxy client requests to [...]
 ```
+
+## Configuration flags
+
+### etcd cluster
+
+#### --endpoints
+
+ * Comma-separated list of etcd server targets for forwarding client connections.
+ * Default: `127.0.0.1:2379`
+ * Invalid example: `https://127.0.0.1:2379` (gateway does not terminate TLS)
+
+#### --discovery-srv
+
+ * DNS domain used to bootstrap cluster endpoints through SRV recrods.
+ * Default: (not set)
+
+### Network
+
+#### --listen-addr
+
+ * Interface and port to bind for accepting client requests.
+ * Default: `127.0.0.1:23790`
+
+#### --retry-delay
+
+ * Duration of delay before retrying to connect to failed endpoints.
+ * Default: 1m0s
+ * Invalid example: "123" (expects time unit in format)
+
+### Security
+
+#### --insecure-discovery
+
+ * Accept SRV records that are insecure or susceptible to man-in-the-middle attacks.
+ * Default: `false`
+
+#### --trusted-ca-file
+
+ * Path to the client TLS CA file for the etcd cluster. Used to authenticate endpoints.
+ * Default: (not set)