Fix typo in API

Signed-off-by: Vojtech Vitek (V-Teq) <vvitek@redhat.com>
duda · Aug 8, 2014 · ce4fcc4 · ce4fcc4
1 parent adc57da
commit ce4fcc4
Show file tree

Hide file tree

Showing 2 changed files with 2 additions and 2 deletions.
diff --git a/api/kubernetes.html b/api/kubernetes.html
@@ -107,7 +107,7 @@
         .method_description p:last-child {
             margin: 0;
         }
-    </style></head><body data-spy=scroll data-target=#sidebar><div class=container><div class=row><div class=col-md-9 role=main><div class=page-header><h1>Kubernetes API documentation <small>version v1beta1</small></h1><p>http://server/api/v1beta1</p><h3 id=Overview><a href=#Overview>Overview</a></h3><p>The Kubernetes API currently manages 3 main resources: <code>pods</code>, <code>replicationControllers</code>, and <code>services</code>. Pods correspond to colocated groups of <a href=http://docker.io>Docker containers</a> with shared volumes, as supported by <a href=https://developers.google.com/compute/docs/containers>Google Cloud Platform&#39;s container-vm images</a>. Singleton pods can be created directly via the <code>/pods</code> endpoint. Sets of pods may created, maintained, and scaled using replicationControllers. Services create load-balanced targets for sets of pods.</p><h3 id=Resource-identifiers><a href=#Resource-identifiers>Resource identifiers</a></h3><p>Each resource has a string <code>id</code> and list of key-value <code>labels</code>. The <code>id</code> is generated by the system and is guaranteed to be unique in space and time across all resources. <code>labels</code> is a map of string (key) to string (value). Each resource may have at most one label with a particular key. Individual labels are used to specify identifying metadata that can be used to define sets of resources by specifying required labels. Examples of typical pod label keys include <code>stage</code>, <code>service</code>, <code>name</code>, <code>tier</code>, <code>partition</code>, and <code>track</code>, but you are free to develop your own conventions.</p><h3 id=Creation-semantics><a href=#Creation-semantics>Creation semantics</a></h3><p>Creation is currently not idempotent. We plan to add a modification token to each resource. A unique value for the token should be provided by the user during creation. If the user specifies a duplicate token at creation time, the system should return an error with a pointer to the exiting resource with that token. In this way a user can deterministically recover from a dropped connection during a resource creation request.</p><h3 id=Update-semantics><a href=#Update-semantics>Update semantics</a></h3><p>Custom verbs are minimized and are used only for &#39;edge triggered&#39; actions such as a reboot. Resource descriptions are generally set up with <code>desiredState</code> for the user provided parameters and <code>currentState</code> for the actual system state. While consistent terminology is used across these two stanzas they do not match member for member.</p><p>When a new version of a resource is PUT the <code>desiredState</code> is updated and available immediately. Over time the system will work to bring the <code>currentState</code> into line with the <code>desiredState</code>. The system will drive toward the most recent <code>desiredState</code> regardless of previous versions of that stanza. In other words, if a value is changed from 2 to 5 in one PUT and then back down to 3 in another PUT the system isn&#39;t required to &#39;touch base&#39; at 5 before making 3 the <code>currentState</code>.</p><p>When doing an update, we assume that the entire <code>desiredState</code> stanza is specified. If a field is omitted it is assumed that the user is looking to delete that field. It is viable for a user to GET the resource, modify what they like in the <code>desiredState</code> or labels stanzas and then PUT it back. If the <code>currentState</code> is included in the PUT it will be silently ignored.</p><p>While currently unspecified, it is intended that concurrent modification should be accomplished with optimistic locking of resources. We plan to add a modification token to each resource. If this is included with the PUT operation the system will verify that there haven&#39;t been other successful mutations to the resource during a read/modify/write cycle. The correct client action at this point is to GET the resource again, apply the changes afresh and try submitting again.</p><p>Note that updates currently only work for replicationControllers and services, but not for pods. Label updates have not yet been implemented, either.</p></div><div class="panel panel-default"><div class=panel-heading><h3 id=_pods class=panel-title>/pods</h3></div><div class=panel-body><div class=panel-group><div class="panel panel-white"><div class=panel-heading><h4 class=panel-title><a class=collapsed data-toggle=collapse href=#panel__pods><span class=parent></span>/pods</a> <span class=methods><a href=# data-toggle=modal data-target=#_pods_get><span class="badge badge_get">get</span></a> <a href=# data-toggle=modal data-target=#_pods_post><span class="badge badge_post">post</span></a></span></h4></div><div id=panel__pods class="panel-collapse collapse"><div class=panel-body><div class=list-group><a href=# data-toggle=modal data-target=#_pods_get class=list-group-item><span class="badge badge_get">get</span><div class=method_description><p>List all pods on this cluster</p></div><div class=clearfix></div></a> <a href=# data-toggle=modal data-target=#_pods_post class=list-group-item><span class="badge badge_post">post</span><div class=method_description><p>Create a new pod. currentState is ignored if present.</p></div><div class=clearfix></div></a></div></div></div><div class="modal fade" tabindex=0 id=_pods_get><div class=modal-dialog><div class=modal-content><div class=modal-header><button type=button class=close data-dismiss=modal aria-hidden=true>&times;</button><h4 class=modal-title id=myModalLabel><span class="badge badge_get">get</span> <span class=parent></span>/pods</h4></div><div class=modal-body><div class="alert alert-info"><p>List all pods on this cluster</p></div><ul class="nav nav-tabs"><li class=active><a href=#_pods_get_request data-toggle=tab>Request</a></li><li><a href=#_pods_get_response data-toggle=tab>Response</a></li></ul><div class=tab-content><div class="tab-pane active" id=_pods_get_request></div><div class=tab-pane id=_pods_get_response><h2>HTTP status code <a href=http://httpstatus.es/200 target=_blank>200</a></h2><h3>Body</h3><p><strong>Type: application/json</strong></p><p><small><strong>Example</strong>:<pre><code>{
+    </style></head><body data-spy=scroll data-target=#sidebar><div class=container><div class=row><div class=col-md-9 role=main><div class=page-header><h1>Kubernetes API documentation <small>version v1beta1</small></h1><p>http://server/api/v1beta1</p><h3 id=Overview><a href=#Overview>Overview</a></h3><p>The Kubernetes API currently manages 3 main resources: <code>pods</code>, <code>replicationControllers</code>, and <code>services</code>. Pods correspond to colocated groups of <a href=http://docker.io>Docker containers</a> with shared volumes, as supported by <a href=https://developers.google.com/compute/docs/containers>Google Cloud Platform&#39;s container-vm images</a>. Singleton pods can be created directly via the <code>/pods</code> endpoint. Sets of pods may created, maintained, and scaled using replicationControllers. Services create load-balanced targets for sets of pods.</p><h3 id=Resource-identifiers><a href=#Resource-identifiers>Resource identifiers</a></h3><p>Each resource has a string <code>id</code> and list of key-value <code>labels</code>. The <code>id</code> is generated by the system and is guaranteed to be unique in space and time across all resources. <code>labels</code> is a map of string (key) to string (value). Each resource may have at most one label with a particular key. Individual labels are used to specify identifying metadata that can be used to define sets of resources by specifying required labels. Examples of typical pod label keys include <code>stage</code>, <code>service</code>, <code>name</code>, <code>tier</code>, <code>partition</code>, and <code>track</code>, but you are free to develop your own conventions.</p><h3 id=Creation-semantics><a href=#Creation-semantics>Creation semantics</a></h3><p>Creation is currently not idempotent. We plan to add a modification token to each resource. A unique value for the token should be provided by the user during creation. If the user specifies a duplicate token at creation time, the system should return an error with a pointer to the existing resource with that token. In this way a user can deterministically recover from a dropped connection during a resource creation request.</p><h3 id=Update-semantics><a href=#Update-semantics>Update semantics</a></h3><p>Custom verbs are minimized and are used only for &#39;edge triggered&#39; actions such as a reboot. Resource descriptions are generally set up with <code>desiredState</code> for the user provided parameters and <code>currentState</code> for the actual system state. While consistent terminology is used across these two stanzas they do not match member for member.</p><p>When a new version of a resource is PUT the <code>desiredState</code> is updated and available immediately. Over time the system will work to bring the <code>currentState</code> into line with the <code>desiredState</code>. The system will drive toward the most recent <code>desiredState</code> regardless of previous versions of that stanza. In other words, if a value is changed from 2 to 5 in one PUT and then back down to 3 in another PUT the system isn&#39;t required to &#39;touch base&#39; at 5 before making 3 the <code>currentState</code>.</p><p>When doing an update, we assume that the entire <code>desiredState</code> stanza is specified. If a field is omitted it is assumed that the user is looking to delete that field. It is viable for a user to GET the resource, modify what they like in the <code>desiredState</code> or labels stanzas and then PUT it back. If the <code>currentState</code> is included in the PUT it will be silently ignored.</p><p>While currently unspecified, it is intended that concurrent modification should be accomplished with optimistic locking of resources. We plan to add a modification token to each resource. If this is included with the PUT operation the system will verify that there haven&#39;t been other successful mutations to the resource during a read/modify/write cycle. The correct client action at this point is to GET the resource again, apply the changes afresh and try submitting again.</p><p>Note that updates currently only work for replicationControllers and services, but not for pods. Label updates have not yet been implemented, either.</p></div><div class="panel panel-default"><div class=panel-heading><h3 id=_pods class=panel-title>/pods</h3></div><div class=panel-body><div class=panel-group><div class="panel panel-white"><div class=panel-heading><h4 class=panel-title><a class=collapsed data-toggle=collapse href=#panel__pods><span class=parent></span>/pods</a> <span class=methods><a href=# data-toggle=modal data-target=#_pods_get><span class="badge badge_get">get</span></a> <a href=# data-toggle=modal data-target=#_pods_post><span class="badge badge_post">post</span></a></span></h4></div><div id=panel__pods class="panel-collapse collapse"><div class=panel-body><div class=list-group><a href=# data-toggle=modal data-target=#_pods_get class=list-group-item><span class="badge badge_get">get</span><div class=method_description><p>List all pods on this cluster</p></div><div class=clearfix></div></a> <a href=# data-toggle=modal data-target=#_pods_post class=list-group-item><span class="badge badge_post">post</span><div class=method_description><p>Create a new pod. currentState is ignored if present.</p></div><div class=clearfix></div></a></div></div></div><div class="modal fade" tabindex=0 id=_pods_get><div class=modal-dialog><div class=modal-content><div class=modal-header><button type=button class=close data-dismiss=modal aria-hidden=true>&times;</button><h4 class=modal-title id=myModalLabel><span class="badge badge_get">get</span> <span class=parent></span>/pods</h4></div><div class=modal-body><div class="alert alert-info"><p>List all pods on this cluster</p></div><ul class="nav nav-tabs"><li class=active><a href=#_pods_get_request data-toggle=tab>Request</a></li><li><a href=#_pods_get_response data-toggle=tab>Response</a></li></ul><div class=tab-content><div class="tab-pane active" id=_pods_get_request></div><div class=tab-pane id=_pods_get_response><h2>HTTP status code <a href=http://httpstatus.es/200 target=_blank>200</a></h2><h3>Body</h3><p><strong>Type: application/json</strong></p><p><small><strong>Example</strong>:<pre><code>{
     "kind": "PodList",
     "apiVersion": "v1beta1",
     "items": [

diff --git a/api/kubernetes.raml b/api/kubernetes.raml
@@ -36,7 +36,7 @@ documentation:
      modification token to each resource. A unique value for the token
      should be provided by the user during creation. If the user
      specifies a duplicate token at creation time, the system should
-     return an error with a pointer to the exiting resource with that
+     return an error with a pointer to the existing resource with that
      token. In this way a user can deterministically recover from a
      dropped connection during a resource creation request.