Merge branch 'master' into master

docs/user-guide/persistent-volumes/index.md

@@ -238,7 +238,7 @@ equal to `""` is always interpreted to be requesting a PV with no class, so it
 can only be bound to PVs with no class (no annotation or one set equal to
 `""`). A PVC with no annotation is not quite the same and is treated differently
 by the cluster depending on whether the
-[`DefaultStorageClass` admission plugin](docs/admin/admission-controllers/#defaultstorageclass)
+[`DefaultStorageClass` admission plugin](/docs/admin/admission-controllers/#defaultstorageclass)
 is turned on.
 
 * If the admission plugin is turned on, the administrator may specify a
@@ -256,7 +256,8 @@ same way as PVCs that have their annotation set to `""`.
 
 When a PVC specifies a `selector` in addition to requesting a `StorageClass`,
 the requirements are ANDed together: only a PV of the requested class and with
-the requested labels may be bound to the PVC.
+the requested labels may be bound to the PVC. Note that currently, a PVC with a
+non-empty `selector` can't have a PV dynamically provisioned for it.
 
 In the future after beta, the `volume.beta.kubernetes.io/storage-class`
 annotation will become an attribute.
@@ -295,13 +296,12 @@ dynamically provisioned.
 
 The name of a `StorageClass` object is significant, and is how users can
 request a particular class. Administrators set the name and other parameters
-of a class, all of which are opaque to users, when first creating
-`StorageClass` objects, and the objects cannot be updated once they are
-created.
+of a class when first creating `StorageClass` objects, and the objects cannot
+be updated once they are created.
 
 Administrators can specify a default `StorageClass` just for PVCs that don't
 request any particular class to bind to: see the
-[`PersistentVolumeClaim` section](docs/user-guide/persistent-volumes/#class-1)
+[`PersistentVolumeClaim` section](#persistentvolumeclaims)
 for details.
 
 ```yaml
@@ -373,16 +373,14 @@ provisioner: kubernetes.io/glusterfs
 parameters:
   endpoint: "glusterfs-cluster"
   resturl: "http://127.0.0.1:8081"
-  restauthenabled: "true"
   restuser: "admin"
   restuserkey: "password"
 ```
 
 * `endpoint`: `glusterfs-cluster` is the endpoint/service name which includes GlusterFS trusted pool IP addresses and this parameter is mandatory.
-* `resturl` : Gluster REST service url which provision gluster volumes on demand. The format should be `IPaddress:Port` and this is a mandatory parameter for GlusterFS dynamic provisioner.
-* `restauthenabled` : Gluster REST service authentication boolean is required if the authentication is enabled on the REST server. If this value is 'true', 'restuser' and 'restuserkey' have to be filled.
-* `restuser` : Gluster REST service user who has access to create volumes in the Gluster Trusted Pool.
-* `restuserkey` : Gluster REST service user's password which will be used for authentication to the REST server.
+* `resturl` : Gluster REST service url which provision gluster volumes on demand. The format should be a valid URL and this is a mandatory parameter for GlusterFS dynamic provisioner.
+* `restuser` : Gluster REST service user who has access to create volumes in the Gluster Trusted Pool. This parameter is optional, empty string will be used when omitted.
+* `restuserkey` : Gluster REST service user's password which will be used for authentication to the REST server. This parameter is optional, empty string will be used when omitted.
 
 #### OpenStack Cinder
 

docs/user-guide/replication-controller/index.md

@@ -114,7 +114,7 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.
 The replication controller can itself have labels (`.metadata.labels`).  Typically, you
 would set these the same as the `.spec.template.metadata.labels`; if `.metadata.labels` is not specified
 then it is defaulted to  `.spec.template.metadata.labels`.  However, they are allowed to be
-different, and the `.metadata.labels` do not affec the behavior of the replication controller.
+different, and the `.metadata.labels` do not affect the behavior of the replication controller.
 
 ### Pod Selector
 
@@ -254,8 +254,8 @@ Use a [`Job`](/docs/user-guide/jobs/) instead of a replication controller for po
 ### DaemonSet
 
 Use a [`DaemonSet`](/docs/admin/daemons/) instead of a replication controller for pods that provide a
-machine-level function, such as machine monitoring or machine logging.  These pods have a lifetime is tied
-to machine lifetime: the pod needs to be running on the machine before other pods start, and are
+machine-level function, such as machine monitoring or machine logging.  These pods have a lifetime that is tied
+to a machine lifetime: the pod needs to be running on the machine before other pods start, and are
 safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
 
 ## For more information

docs/user-guide/secrets/index.md

@@ -642,8 +642,6 @@ you must use `ls -la` to see them when listing directory contents.
 
 ### Use-case: Secret visible to one container in a pod
 
-<a name="use-case-two-containers"></a>
-
 Consider a program that needs to handle HTTP requests, do some complex business
 logic, and then sign some messages with an HMAC.  Because it has complex
 application logic, there might be an unnoticed remote file reading exploit in
@@ -688,7 +686,7 @@ Therefore, one Pod does not have access to the secrets of another pod.
 There may be several containers in a pod.  However, each container in a pod has
 to request the secret volume in its `volumeMounts` for it to be visible within
 the container.  This can be used to construct useful [security partitions at the
-Pod level](#use-case-two-containers).
+Pod level](#use-case-secret-visible-to-one-container-in-a-pod).
 
 ### Risks