openstack
/
api-sig
Code Issues Proposed changes

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
This commit is contained in:
Ken'ichi Ohmichi 2015-08-03 01:26:16 +00:00 committed by Ken'ichi Ohmichi
parent 07a7aafbf3
commit 53eeb66d39
1 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
guidelines/terms.rst
View File

@ -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.