Merge pull request #6313 from krousey/design_doc_fix

Changing the case of API to be consistent with surrounding uses.
kubernetes · Apr 1, 2015 · 4191c94 · 4191c94
2 parents 6bdb3bf + 547ee5b
commit 4191c94
Showing 1 changed file with 1 addition and 1 deletion.
diff --git a/docs/design/identifiers.md b/docs/design/identifiers.md
@@ -39,7 +39,7 @@ Name
 1. When an object is created via an API, a Name string (a DNS_SUBDOMAIN) must be specified.  Name must be non-empty and unique within the apiserver.  This enables idempotent and space-unique creation operations.  Parts of the system (e.g. replication controller) may join strings (e.g. a base name and a random suffix) to create a unique Name.  For situations where generating a name is impractical, some or all objects may support a param to auto-generate a name.  Generating random names will defeat idempotency.
    * Examples: "guestbook.user", "backend-x4eb1"
 
-2. When an object is created via an api, a Namespace string (a DNS_SUBDOMAIN? format TBD via #1114) may be specified.  Depending on the API receiver, namespaces might be validated (e.g. apiserver might ensure that the namespace actually exists).  If a namespace is not specified, one will be assigned by the API receiver.  This assignment policy might vary across API receivers (e.g. apiserver might have a default, kubelet might generate something semi-random).
+2. When an object is created via an API, a Namespace string (a DNS_SUBDOMAIN? format TBD via #1114) may be specified.  Depending on the API receiver, namespaces might be validated (e.g. apiserver might ensure that the namespace actually exists).  If a namespace is not specified, one will be assigned by the API receiver.  This assignment policy might vary across API receivers (e.g. apiserver might have a default, kubelet might generate something semi-random).
    * Example: "api.k8s.example.com"
 
 3. Upon acceptance of an object via an API, the object is assigned a UID (a UUID).  UID must be non-empty and unique across space and time.