openstack/api-sig
Code Issues Proposed changes

Add the condition for using a project term

Browse Source 
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** * **project name** vs. **service type**
Each OpenStack project has both a "project name" (e.g., Nova, Keystone, etc.) Most OpenStack projects have both a "project name" (e.g., Nova, Keystone,
and a "service type" (e.g., Compute, Identity, etc.). Some REST API features etc.) and a "service type" (e.g., Compute, Identity, etc.). Some REST API
(e.g., JSON-Home, API Microversions, etc.) need to expose each project in a features (e.g., JSON-Home, API Microversions, etc.) need to expose each
request/response. project in a request/response.
The project *should* be represented with its **service type** because its The project *should* be represented with its **service type** if it has both
project name is subject to change (e.g., Neutron was Quantum) and its service a "project name" and a "service type" because its project name is subject to
type is more stable. The service type should come from "type" of the change (e.g., Neutron was Quantum) and its service type is more stable. The
corresponding OpenStack Identity service catalog entry. service type should come from "type" of the corresponding OpenStack Identity
service catalog entry.