openstack
/
glance-specs
Code Issues Proposed changes

Fix spelling of 'OpenStack' in spec docs 

According to the word choice convention in
http://docs.openstack.org/contributor-guide/writing-style/word-choice.html
We should use OpenStack instead of Openstack or openstack.

TrivialFix

Change-Id: I341f45c57b0fa68de9d185c551d9d570ccf1a4fb
This commit is contained in:
melissaml 2016-10-24 15:23:23 +08:00
parent 4468577808
commit 12026065cf
4 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
specs/kilo/artifact-repository.rst
View File

@ -21,7 +21,7 @@ binary objects.
Problem description
===================
Various Openstack services often need to catalog different objects they use to
Various OpenStack services often need to catalog different objects they use to
operate. Such objects may contain various data as well as metadata needed for
identification and description.
@ -638,9 +638,9 @@ Then, Swift has a different level of abstraction: it does not care about the
data which is being stored within it, while Glance should be aware of the
artifact types specifics.
Last but not least, many production-grade Openstack deployments do not have
Last but not least, many production-grade OpenStack deployments do not have
Swift deployed, as they do not need it. Meanwhile, Glance is present on each
and every Openstack cloud.
and every OpenStack cloud.
Meanwhile, Swift still may be used as an underlying storage for artifacts - in
the same way as Glance uses it to store Images.

8
specs/kilo/semver-support.rst
View File

@ -52,7 +52,7 @@ properly process the version objects in memory. There is a number of mature
libraries which have this functionality and there is no need to re-implement
them.
After some research it has been suggested to use "semantic_version" library
which is available at pypi [2]. This library is not present in openstack global
which is available at pypi [2]. This library is not present in OpenStack global
requirements, so a patchset [3] has been submitted to add it there.
To be able to sort these version objects in the database it is required to
@ -155,12 +155,12 @@ standard seems preferable.
There is one more standard which stands between semver and pep440. It is
called "Linux Compatible Semantic Versioning 3.0.0", is a fork of regular
semver (its 2.0 version) and is developed within Openstack community [5]. It
semver (its 2.0 version) and is developed within OpenStack community [5]. It
tries to blend regular semver with versions of Linux Distribution packages and
uses some concepts of pep440 for it.
This notation is easier to map to the database type, however it is still local
to relatively small community of developers (Openstack developers in this
to relatively small community of developers (OpenStack developers in this
case), so more generic and widely adopted standard as semver seems more
preferrable.
@ -245,7 +245,7 @@ However it seems preferable to add this support to semantic_version library [2]
and remove it from glance codebase aftwerwards.
If the maintainer of the library does not accept this functionality (or if we
decide to add support for more versioning notations later) then this code may
be transferred to some common openstack library, such as Oslo.
be transferred to some common OpenStack library, such as Oslo.
After this feature is implemented we should continue the work to add support
for other versioning schemas, such as pep440, Linux Compatible Semantic

4
specs/mitaka/approved/image-import/image-import-refactor.rst
View File

@ -163,7 +163,7 @@ First, background, so you can see what problems needed to be addressed:
#. The "Tasks" API is a disaster from the interoperability and discoverability
standpoint. (We know this because at least one large public cloud has
exposed image import via Glance Tasks, and the openstack infra team has a
exposed image import via Glance Tasks, and the OpenStack infra team has a
lot to say about how bad it is. Just ask them.)
#. interoperability failures: The Task object, as defined by
@ -174,7 +174,7 @@ First, background, so you can see what problems needed to be addressed:
#. discoverability failures: You don't have to support a particular
disk/container format, but there must be a way to find out what a
particular cloud supports (and this "way" should be the same for all
openstack clouds, and no, documentation doesn't count)
OpenStack clouds, and no, documentation doesn't count)
#. There are three cases for "image upload" that Glance should support.

2
specs/mitaka/implemented/cim-namespace-metadata-definitions.rst
View File

@ -155,7 +155,7 @@ Testing
=======
1. Tests to confirm our parsing is valid
2. Tests to confirm the metadata has been uploaded correctly in Openstack
2. Tests to confirm the metadata has been uploaded correctly in OpenStack
Documentation Impact
====================