From 49cd4c440a5711f81ab0ca797daa422aa92af8d7 Mon Sep 17 00:00:00 2001
From: Frank Budinsky <frankb@ca.ibm.com>
Date: Mon, 19 Jun 2017 21:15:20 -0400
Subject: [PATCH] some doc corrections (#394)

---
 .../traffic-management/rules-configuration.md | 31 ++++++++++---------
 .../traffic-rules/destination-policies.md     |  2 --
 .../config/traffic-rules/routing-rules.md     | 18 +++++------
 _posts/2017-06-14-0.1-canary.md               |  2 +-
 4 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/_docs/concepts/traffic-management/rules-configuration.md b/_docs/concepts/traffic-management/rules-configuration.md
index 48c36def3a..a41cfeb41f 100644
--- a/_docs/concepts/traffic-management/rules-configuration.md
+++ b/_docs/concepts/traffic-management/rules-configuration.md
@@ -319,9 +319,11 @@ the "reviews" microservice.
 
 ```yaml
 destination: reviews.default.svc.cluster.local
-tags:
-  version: v1
-loadBalancing: RANDOM
+policy:
+- tags:
+    version: v1
+  loadBalancing:
+    name: RANDOM
 ```
 
 ### Circuit breakers
@@ -333,11 +335,12 @@ sets a limit of 100 connections to "reviews" service version "v1" backends.
 
 ```yaml
 destination: reviews.default.svc.cluster.local
-tags:
-  version: v1
-circuitBreaker:
-  simpleCb:
-    maxConnections: 100
+policy:
+- tags:
+    version: v1
+  circuitBreaker:
+    simpleCb:
+      maxConnections: 100
 ```
 
 The complete set of simple circuit breaker fields can be found
@@ -363,11 +366,12 @@ consider the following rule, as the one and only rule defined for the
 
 ```yaml
 destination: reviews.default.svc.cluster.local
-tags:
-  version: v1
-circuitBreaker:
-  simpleCb:
-    maxConnections: 100
+policy:
+- tags:
+    version: v1
+  circuitBreaker:
+    simpleCb:
+      maxConnections: 100
 ```
 
 Since there is no specific route rule defined for the "reviews"
@@ -394,6 +398,5 @@ Although the default Istio behavior conveniently sends traffic from all
 versions of a source service to all versions of a destination service
 without any rules being set, as soon as version discrimination is desired
 rules are going to be needed.
-
 Therefore, setting a default rule for every service, right from the
 start, is generally considered a best practice in Istio.
diff --git a/_docs/reference/config/traffic-rules/destination-policies.md b/_docs/reference/config/traffic-rules/destination-policies.md
index d737ebb298..9f9cfa5f86 100644
--- a/_docs/reference/config/traffic-rules/destination-policies.md
+++ b/_docs/reference/config/traffic-rules/destination-policies.md
@@ -22,8 +22,6 @@ look as follows:
     policy:
     - loadBalancing: 
         name: RANDOM
-      simpleCb:
-        maxConnections: 1000
 
 
 Policies are applicable per individual service versions. ONLY
diff --git a/_docs/reference/config/traffic-rules/routing-rules.md b/_docs/reference/config/traffic-rules/routing-rules.md
index 27680952fb..1a73fd3165 100644
--- a/_docs/reference/config/traffic-rules/routing-rules.md
+++ b/_docs/reference/config/traffic-rules/routing-rules.md
@@ -277,8 +277,8 @@ ratings service before making the actual API call.
     rewrite:
       uri: /v1/bookRatings
     route:
-      - tags:
-          version: v1
+    - tags:
+        version: v1
 
 <table>
  <tr>
@@ -310,9 +310,9 @@ Describes HTTP request timeout. For example, the following rule sets a
     route:
     - tags:
         version: v1
-      httpReqTimeout:
-        simpleTimeout:
-          timeout: 10s
+    httpReqTimeout:
+      simpleTimeout:
+        timeout: 10s
 
 <table>
  <tr>
@@ -356,10 +356,10 @@ calling ratings:v1 service, with a 2s timeout per retry attempt.
     route:
     - tags:
         version: v1
-      httpReqRetries:
-        simpleRetry:
-          attempts: 3
-          perTryTimeout: 2s
+    httpReqRetries:
+      simpleRetry:
+        attempts: 3
+        perTryTimeout: 2s
 
 <table>
  <tr>
diff --git a/_posts/2017-06-14-0.1-canary.md b/_posts/2017-06-14-0.1-canary.md
index af071c3aa9..e31cbe8c1f 100644
--- a/_posts/2017-06-14-0.1-canary.md
+++ b/_posts/2017-06-14-0.1-canary.md
@@ -197,7 +197,7 @@ As before, the autoscalers bound to the 2 version Deployments will automatically
 
 ## Summary
 
-In this article we’ve shown how Istio supports general scalable canary deployments, and how this differs from the basic deployment support in Kubernetes. Istio’s service mesh provides the control necessary to manage traffic distribution with complete independence from deployment scaling. This allows for a simpler, yet significantly more functional, way to do canary test and rolloout. 
+In this article we’ve shown how Istio supports general scalable canary deployments, and how this differs from the basic deployment support in Kubernetes. Istio’s service mesh provides the control necessary to manage traffic distribution with complete independence from deployment scaling. This allows for a simpler, yet significantly more functional, way to do canary test and rollout. 
 
 Intelligent routing in support of canary deployment is just one of the many features of Istio that will make the production deployment of large-scale microservices-based applications much simpler. Check out [istio.io]({{home}}) for more information and to try it out.
 The sample code used in this article can be found [here](https://github.com/istio/istio/tree/master/samples/apps/helloworld).
\ No newline at end of file