diff --git a/doc/source/dev/api_microversion.rst b/doc/source/dev/api_microversion.rst index a44fd89fae..a240ce8d91 100644 --- a/doc/source/dev/api_microversion.rst +++ b/doc/source/dev/api_microversion.rst @@ -161,7 +161,7 @@ we need a microversion". previously unspecified error code is the 400, 403, 404 and 415 cases. This is considered OK to return even if previously unspecified in the code since it's implied given keystone authentication can fail with a 403 and API - validation can fail with a 400 for invalid json request body. Request to + validation can fail with a 400 for invalid JSON request body. Request to url/resource that does not exist always fails with 404. Invalid content types are handled before API methods are called which results in a 415. diff --git a/doc/source/troubleshooting-guide.rst b/doc/source/troubleshooting-guide.rst index a92f867385..318897eca6 100644 --- a/doc/source/troubleshooting-guide.rst +++ b/doc/source/troubleshooting-guide.rst @@ -609,7 +609,7 @@ Check the following: curl http://:2379/v2/keys/coreos.com/network/subnets - You should receive a json snippet that describes all the segments + You should receive a JSON snippet that describes all the segments allocated. - This network segment is passed to Docker via the parameter *--bip*. diff --git a/doc/source/userguide.rst b/doc/source/userguide.rst index b8db34909b..bc5ed6ca1a 100644 --- a/doc/source/userguide.rst +++ b/doc/source/userguide.rst @@ -1317,11 +1317,11 @@ _`mesos_slave_executor_env_variables` environment variables to the executor and subsequent tasks. For more details, refer to the `Mesos configuration `_. - Valid value is the name of a json file, for example:: + Valid value is the name of a JSON file, for example:: mesos_slave_executor_env_variables=/home/ubuntu/test.json - The json file should contain environment variables, for example:: + The JSON file should contain environment variables, for example:: { "PATH": "/bin:/usr/bin", @@ -2152,7 +2152,7 @@ Flocker. Magnum currently supports Rexray as the volume driver for Swarm and Mesos. Other drivers are being considered. Kubernetes allows a previously created Cinder block to be mounted to -a pod and this is done by specifying the block ID in the pod yaml file. +a pod and this is done by specifying the block ID in the pod YAML file. When the pod is scheduled on a node, Kubernetes will interface with Cinder to request the volume to be mounted on this node, then Kubernetes will launch the Docker container with the proper options to @@ -2289,7 +2289,7 @@ Following is an example illustrating how Cinder is used in a pod. fsType: ext4 END -**NOTE:** The Cinder volume ID needs to be configured in the yaml file +**NOTE:** The Cinder volume ID needs to be configured in the YAML file so the existing Cinder volume can be mounted in a pod by specifying the volume ID in the pod manifest as follows:: @@ -2374,7 +2374,7 @@ Using Cinder in Mesos **NOTE:** When the Mesos cluster is created using this ClusterTemplate, the Mesos cluster will be configured so that a filesystem on an existing cinder volume can be mounted in a container by configuring the parameters to mount -the cinder volume in the json file :: +the cinder volume in the JSON file :: "parameters": [ { "key": "volume-driver", "value": "rexray" },