From 96c5896c747800cef75c6e5e9251fd8aabf7702f Mon Sep 17 00:00:00 2001
From: Benjamen Keroack <benjamen.keroack@dollarshaveclub.com>
Date: Wed, 6 May 2015 17:37:31 -0700
Subject: [PATCH] service documentation: fix location of selector in JSON, make
 it clear that publicIPs belongs in the spec field

---
 docs/services.md | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/docs/services.md b/docs/services.md
index ff16da7374b..d4db060eefd 100644
--- a/docs/services.md
+++ b/docs/services.md
@@ -43,12 +43,15 @@ port 9376 and carry a label "app=MyApp".
     "kind": "Service",
     "apiVersion": "v1beta3",
     "metadata": {
-        "name": "my-service"
-    },
-    "selector": {
-        "app": "MyApp"
+        "name": "my-service",
+        "labels": {
+            "environment": "testing"
+        }
     },
     "spec": {
+        "selector": {
+            "app": "MyApp"
+        },
         "ports": [
             {
                 "protocol": "TCP",
@@ -235,9 +238,9 @@ address.
 On cloud providers which support external load balancers, this should be as
 simple as setting the `createExternalLoadBalancer` flag of the `Service` spec
 to `true`.  This sets up a cloud-specific load balancer and populates the
-`publicIPs` field (see below).  Traffic from the external load balancer will be
-directed at the backend `Pods`, though exactly how that works depends on the
-cloud provider.
+`publicIPs` field of the spec (see below).  Traffic from the external load 
+balancer will be directed at the backend `Pods`, though exactly how that works 
+depends on the cloud provider.
 
 For cloud providers which do not support external load balancers, there is
 another approach that is a bit more "do-it-yourself" - the `publicIPs` field.