From 53eeb66d39a1723aa4aa80409eff4952a707e4a7 Mon Sep 17 00:00:00 2001 From: Ken'ichi Ohmichi Date: Mon, 3 Aug 2015 01:26:16 +0000 Subject: [PATCH] Add the condition for using a project term Most projects contain both their own project name and service name, and **project name** vs. **service type** guideline is defined for most cases. However, on current big-tent trend, some projects don't contain them. So this patch makes the guideline clear for most cases. Change-Id: I75cabcf0787073d96b6536c4e70b63ed73b814e3 --- guidelines/terms.rst | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/guidelines/terms.rst b/guidelines/terms.rst index ed84c96..cbc8f5b 100644 --- a/guidelines/terms.rst +++ b/guidelines/terms.rst @@ -28,11 +28,12 @@ made regarding certain terms, and attempts to succinctly define each term. * **project name** vs. **service type** - Each OpenStack project has both a "project name" (e.g., Nova, Keystone, etc.) - and a "service type" (e.g., Compute, Identity, etc.). Some REST API features - (e.g., JSON-Home, API Microversions, etc.) need to expose each project in a - request/response. - The project *should* be represented with its **service type** because its - project name is subject to change (e.g., Neutron was Quantum) and its service - type is more stable. The service type should come from "type" of the - corresponding OpenStack Identity service catalog entry. + Most OpenStack projects have both a "project name" (e.g., Nova, Keystone, + etc.) and a "service type" (e.g., Compute, Identity, etc.). Some REST API + features (e.g., JSON-Home, API Microversions, etc.) need to expose each + project in a request/response. + The project *should* be represented with its **service type** if it has both + a "project name" and a "service type" because its project name is subject to + change (e.g., Neutron was Quantum) and its service type is more stable. The + service type should come from "type" of the corresponding OpenStack Identity + service catalog entry.