Follow the docs conventions

change capitalization to follow the docs conventions:
https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_project_names

Change-Id: Ib1c596fb9ab39cfe4cf6fbf38d823b38a9632f77

doc/admin-guide-cloud-rst/source/blockstorage_ratelimit_volume_copy_bandwidth.rst

@@ -7,7 +7,7 @@ Rate-limit volume copy bandwidth
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 When you create a new volume from an image or an existing volume, or
-when you upload a volume image to the Image Service, large data copy
+when you upload a volume image to the Image service, large data copy
 may stress disk and network bandwidth. To mitigate slow down of data
 access from the instances, OpenStack Block Storage supports rate-limiting
 of volume data copy bandwidth.

doc/admin-guide-cloud-rst/source/keystone_certificates_for_pki.rst

@@ -10,10 +10,10 @@ public key must be signed in an X509 certificate, and the certificate
 used to sign it must be available as a Certificate Authority (CA)
 certificate. These files can be generated either using the
 ``keystone-manage`` utility, or externally generated. The files need to
-be in the locations specified by the top level Identity Service
+be in the locations specified by the top level Identity service
 configuration file :file:`keystone.conf` as specified in the above section.
 Additionally, the private key should only be readable by the system user
-that will run the Identity Service.
+that will run the Identity service.
 
 
 .. warning::

doc/admin-guide-cloud-rst/source/networking_arch.rst

@@ -10,7 +10,7 @@ Overview
 
 Networking is a standalone component in the OpenStack modular
 architecture. It's positioned alongside OpenStack components such as
-Compute, Image service, Identity, or the Dashboard. Like those
+Compute, Image service, Identity, or dashboard. Like those
 components, a deployment of Networking often involves deploying several
 services to a variety of hosts.
 

doc/admin-guide-cloud-rst/source/networking_auth.rst

@@ -2,15 +2,15 @@
 Authentication and authorization
 ================================
 
-Networking uses the Identity Service as the default authentication
-service. When the Identity Service is enabled, users who submit requests
+Networking uses the Identity service as the default authentication
+service. When the Identity service is enabled, users who submit requests
 to the Networking service must provide an authentication token in
 ``X-Auth-Token`` request header. Users obtain this token by
-authenticating with the Identity Service endpoint. For more information
-about authentication with the Identity Service, see `OpenStack Identity
-Service API v2.0
+authenticating with the Identity service endpoint. For more information
+about authentication with the Identity service, see `OpenStack Identity
+service API v2.0
 Reference <http://developer.openstack.org/api-ref-identity-v2.html>`__.
-When the Identity Service is enabled, it is not mandatory to specify the
+When the Identity service is enabled, it is not mandatory to specify the
 tenant ID for resources in create requests because the tenant ID is
 derived from the authentication token.
 

doc/common-rst/cli_install_openstack_command_line_clients.rst

@@ -211,7 +211,7 @@ installed without ``pip``.
      # yum install python-PROJECTclient
 
 -  For openSUSE, use zypper to install the clients from the distribution
-   packages Service::
+   packages service::
 
      # zypper install python-PROJECT
 

doc/common-rst/get_started_compute.rst

@@ -8,7 +8,7 @@ OpenStack Compute is a major part of an Infrastructure-as-a-Service
 (IaaS) system. The main modules are implemented in Python.
 
 OpenStack Compute interacts with OpenStack Identity for authentication,
-OpenStack Image Service for disk and server images, and OpenStack
+OpenStack Image service for disk and server images, and OpenStack
 dashboard for the user and administrative interface. Image access is
 limited by projects, and by users; quotas are limited per project (the
 number of instances, for example). OpenStack Compute can scale

doc/common-rst/get_started_identity.rst

@@ -28,7 +28,7 @@ User
 Credentials
   Data that confirms the user's identity. For example: user name and
   password, user name and API key, or an authentication token provided
-  by the Identity Service.
+  by the Identity service.
 
 Authentication
   The process of confirming the identity of a user. OpenStack Identity

doc/common-rst/get_started_image_service.rst

@@ -1,9 +1,9 @@
 .. :orphan:
 
-OpenStack Image Service
+OpenStack Image service
 -----------------------
 
-The OpenStack Image Service is central to Infrastructure-as-a-Service
+The OpenStack Image service is central to Infrastructure-as-a-Service
 (IaaS) as shown in Conceptual architecture. It accepts API requests for disk
 or server images, and image metadata from end users or OpenStack Compute
 components. It also supports the storage of disk or server images on various
@@ -11,12 +11,12 @@ repository types, including OpenStack Object Storage.
 
 .. TODO (DC) On line 7, add link to get_started_conceptual_architecture.rst
 
-A number of periodic processes run on the OpenStack Image Service to
+A number of periodic processes run on the OpenStack Image service to
 support caching. Replication services ensure consistency and
 availability through the cluster. Other periodic processes include
 auditors, updaters, and reapers.
 
-The OpenStack Image Service includes the following components:
+The OpenStack Image service includes the following components:
 
 glance-api
   Accepts Image API calls for image discovery, retrieval, and storage.
@@ -28,7 +28,7 @@ glance-registry
   .. note::
 
      The registry is a private internal service meant for use by
-     OpenStack Image Service. Do not disclose it to users.
+     OpenStack Image service. Do not disclose it to users.
 
 Database
   Stores image metadata and you can choose your database depending on

doc/common-rst/support-compute.rst

@@ -46,7 +46,7 @@ configuration settings. In :file:`nova.conf`, include the
 Guru Meditation reports
 -----------------------
 
-A Guru Meditation report is sent by the Compute Service upon receipt of the
+A Guru Meditation report is sent by the Compute service upon receipt of the
 ``SIGUSR1`` signal. This report is a general-purpose error report,
 including a complete report of the service's current state, and is sent to
 ``stderr``.
@@ -133,7 +133,7 @@ the ``nova-compute`` host and make sure that these files are present:
 * :file:`console.log`, after the instance starts.
 
 If any files are missing, empty, or very small, the ``nova-compute``
-service did not successfully download the images from the Image Service.
+service did not successfully download the images from the Image service.
 
 Also check :file:`nova-compute.log` for exceptions. Sometimes they do not
 appear in the console output.