From 0393934828dc7bd9f1b39ca6b478a5ff8dec0320 Mon Sep 17 00:00:00 2001 From: KATO Tomoyuki Date: Wed, 17 Jun 2015 10:52:29 +0900 Subject: [PATCH] Change service names with conventions Follow the Documentaion conventions: https://wiki.openstack.org/wiki/Documentation/Conventions Change-Id: I16078f5bfc3c47002f43f23be83b03c1f6f938fe --- doc/openstack-ops/app_usecases.xml | 8 +++---- .../ch_arch_cloud_controller.xml | 18 +++++++------- doc/openstack-ops/ch_arch_examples.xml | 4 ++-- doc/openstack-ops/ch_arch_storage.xml | 24 +++++++++---------- doc/openstack-ops/ch_ops_backup_recovery.xml | 4 ++-- doc/openstack-ops/ch_ops_customize.xml | 4 ++-- doc/openstack-ops/ch_ops_lay_of_land.xml | 4 ++-- doc/openstack-ops/ch_ops_log_monitor.xml | 4 ++-- doc/openstack-ops/ch_ops_maintenance.xml | 2 +- .../ch_ops_network_troubleshooting.xml | 10 ++++---- doc/openstack-ops/ch_ops_projects_users.xml | 16 ++++++------- doc/openstack-ops/ch_ops_upgrades.xml | 21 +++++++--------- doc/openstack-ops/part_architecture.xml | 2 +- .../section_arch_example-neutron.xml | 10 ++++---- .../section_arch_example-nova.xml | 18 +++++++------- 15 files changed, 73 insertions(+), 76 deletions(-) diff --git a/doc/openstack-ops/app_usecases.xml b/doc/openstack-ops/app_usecases.xml index f2bcfb87..80048f68 100644 --- a/doc/openstack-ops/app_usecases.xml +++ b/doc/openstack-ops/app_usecases.xml @@ -47,10 +47,10 @@ sites span multiple data centers, some use off compute node storage with a shared file system, and some use on compute node storage with a non-shared file system. Each site deploys the Image service with an - Object Storage back end. A central Identity Service, dashboard, and + Object Storage back end. A central Identity, dashboard, and Compute API service are used. A login to the dashboard triggers a SAML login with Shibboleth, which creates an account - in the Identity Service with a SQL back end. An Object Storage Global + in the Identity service with a SQL back end. An Object Storage Global Cluster is used across several sites. Compute nodes have 24 to 48 cores, with at least 4 GB of RAM per @@ -136,7 +136,7 @@ core. With our upgrade to Grizzly in August 2013, we moved to OpenStack - Networking Service, neutron (quantum at the time). Compute nodes have + Networking, neutron (quantum at the time). Compute nodes have two-gigabit network interfaces and a separate management card for IPMI management. One network interface is used for node-to-node communications. The other is used as a trunk port for OpenStack managed @@ -267,7 +267,7 @@ instance provisioning. Users and groups are managed through Active Directory and imported - into the Identity Service using LDAP. CLIs are available for nova + into the Identity service using LDAP. CLIs are available for nova and Euca2ools to do this. There are three clouds currently running at CERN, totaling about diff --git a/doc/openstack-ops/ch_arch_cloud_controller.xml b/doc/openstack-ops/ch_arch_cloud_controller.xml index 3d061463..837f9c78 100644 --- a/doc/openstack-ops/ch_arch_cloud_controller.xml +++ b/doc/openstack-ops/ch_arch_cloud_controller.xml @@ -121,7 +121,7 @@ Offers each service's REST API access, where the API endpoint - catalog is managed by the Identity Service + catalog is managed by the Identity service @@ -321,7 +321,7 @@ This deployment felt that the spare I/O on the Object Storage proxy server was sufficient and that the Image Delivery portion of glance benefited from being on physical hardware and - having good connectivity to the Object Storage backend it was + having good connectivity to the Object Storage back end it was using. @@ -587,7 +587,7 @@ The OpenStack Image service consists of two parts: glance-api and glance-registry. The former is responsible for the delivery of images; the compute node uses it to - download images from the backend. The latter maintains the metadata + download images from the back end. The latter maintains the metadata information associated with virtual machine images and requires a database. glance @@ -612,7 +612,7 @@ The glance-api part is an abstraction layer that allows - a choice of backend. Currently, it supports: + a choice of back end. Currently, it supports: @@ -705,22 +705,22 @@ group. Resources quotas, such as the number of cores that can be used, disk space, and so on, are associated with a project. - The OpenStack Identity Service (keystone) is the point that provides + OpenStack Identity is the service that provides the authentication decisions and user attribute information, which is then used by the other OpenStack services to perform authorization. Policy is set in the policy.json file. For information on how to configure these, see . - Identity Service + Identity authentication decisions - Identity Service + Identity plug-in support - The Identity Service supports different plug-ins for authentication + OpenStack Identity supports different plug-ins for authentication decisions and identity storage. Examples of these plug-ins include: @@ -752,7 +752,7 @@ Because the cloud controller handles so many different services, it must be able to handle the amount of traffic that hits it. For example, if - you choose to host the OpenStack Imaging Service on the cloud controller, + you choose to host the OpenStack Image service on the cloud controller, the cloud controller should be able to support the transferring of the images at an acceptable speed. cloud controllers diff --git a/doc/openstack-ops/ch_arch_examples.xml b/doc/openstack-ops/ch_arch_examples.xml index ef2e332c..ed127cac 100644 --- a/doc/openstack-ops/ch_arch_examples.xml +++ b/doc/openstack-ops/ch_arch_examples.xml @@ -20,7 +20,7 @@ each as well as a rationale for why it worked well in a given environment. - Because OpenStack is highly configurable, with many different backends + Because OpenStack is highly configurable, with many different back ends and network configuration options, it is difficult to write documentation that covers all possible OpenStack deployments. Therefore, this guide defines example architectures to simplify the task of documenting, as well @@ -48,4 +48,4 @@ or the OpenStack User Stories page. - \ No newline at end of file + diff --git a/doc/openstack-ops/ch_arch_storage.xml b/doc/openstack-ops/ch_arch_storage.xml index d3f70c3b..b629570a 100644 --- a/doc/openstack-ops/ch_arch_storage.xml +++ b/doc/openstack-ops/ch_arch_storage.xml @@ -193,8 +193,8 @@ These volumes are persistent: they can be detached from one instance and re-attached to another, and the data remains intact. Block storage is implemented in OpenStack by the OpenStack Block Storage - (cinder) project, which supports multiple backends in the form of - drivers. Your choice of a storage backend must be supported by a Block + (cinder) project, which supports multiple back ends in the form of + drivers. Your choice of a storage back end must be supported by a Block Storage driver. Most block storage drivers allow the instance to have direct @@ -351,14 +351,14 @@ instantly when starting a new instance. For other systems, ephemeral storage—storage that is released when a VM attached to it is shut down— is the preferred way. When you select storage - backends, + back ends, storage - choosing backends + choosing back ends - storage backend + storage back end - backend interactions + back end interactions store ask the following questions on behalf of your users: @@ -609,7 +609,7 @@ Commodity Storage Backend Technologies This section provides a high-level overview of the differences - among the different commodity storage backend technologies. Depending on + among the different commodity storage back end technologies. Depending on your cloud user's needs, you can implement one or many of these technologies in different combinations: storage @@ -661,7 +661,7 @@ storage, and file-system interfaces, although the file-system interface is not yet considered production-ready. Ceph supports the same API as swift for object storage and can be used as a - backend for cinder block storage as well as backend storage for + back end for cinder block storage as well as back-end storage for glance images. Ceph supports "thin provisioning," implemented using copy-on-write. @@ -697,7 +697,7 @@ 3.3, you can use Gluster to consolidate your object storage and file storage into one unified file and object storage solution, which is called Gluster For OpenStack (GFO). GFO uses a customized - version of swift that enables Gluster to be used as the backend + version of swift that enables Gluster to be used as the back-end storage. The main reason to use GFO rather than regular swift is if @@ -717,7 +717,7 @@ The Logical Volume Manager is a Linux-based system that provides an abstraction layer on top of physical disks to expose - logical volumes to the operating system. The LVM backend + logical volumes to the operating system. The LVM back-end implements block storage as LVM logical partitions. On each host that will house block storage, an administrator @@ -748,7 +748,7 @@ number of advantages over ext4, including improved data-integrity checking. - The ZFS backend for OpenStack Block Storage supports only + The ZFS back end for OpenStack Block Storage supports only Solaris-based systems, such as Illumos. While there is a Linux port of ZFS, it is not included in any of the standard Linux distributions, and it has not been tested with OpenStack Block @@ -758,7 +758,7 @@ failures. We don't recommend ZFS unless you have previous experience - with deploying it, since the ZFS backend for Block Storage + with deploying it, since the ZFS back end for Block Storage requires a Solaris-based operating system, and we assume that your experience is primarily with Linux-based systems. diff --git a/doc/openstack-ops/ch_ops_backup_recovery.xml b/doc/openstack-ops/ch_ops_backup_recovery.xml index 2e16c1ac..817e1ebb 100644 --- a/doc/openstack-ops/ch_ops_backup_recovery.xml +++ b/doc/openstack-ops/ch_ops_backup_recovery.xml @@ -166,7 +166,7 @@ find $backup_dir -ctime +7 -type f -delete /var/lib/glance should also be backed up. Take special notice of /var/lib/glance/images. If you are using - a file-based backend of glance, /var/lib/glance/images is + a file-based back end of glance, /var/lib/glance/images is where the images are stored and care should be taken. There are two ways to ensure stability with this directory. The @@ -183,7 +183,7 @@ backup-server:/var/lib/glance/images/ /etc/keystone and /var/log/keystone follow the same rules as other components. - Identity Service + Identity backup/recovery diff --git a/doc/openstack-ops/ch_ops_customize.xml b/doc/openstack-ops/ch_ops_customize.xml index 36468c07..b06618a1 100644 --- a/doc/openstack-ops/ch_ops_customize.xml +++ b/doc/openstack-ops/ch_ops_customize.xml @@ -243,7 +243,7 @@ RABBIT_PASSWORD=devstack SERVICE_PASSWORD=devstack SERVICE_TOKEN=devstack -# OpenStack Identity Service branch +# OpenStack Identity branch KEYSTONE_BRANCH=stable/havana # OpenStack Compute branch @@ -255,7 +255,7 @@ CINDER_BRANCH=stable/havana # OpenStack Image service branch GLANCE_BRANCH=stable/havana -# OpenStack Dashboard branch +# OpenStack dashboard branch HORIZON_BRANCH=stable/havana # OpenStack Object Storage branch diff --git a/doc/openstack-ops/ch_ops_lay_of_land.xml b/doc/openstack-ops/ch_ops_lay_of_land.xml index df6adc2a..b2ba72f7 100644 --- a/doc/openstack-ops/ch_ops_lay_of_land.xml +++ b/doc/openstack-ops/ch_ops_lay_of_land.xml @@ -502,10 +502,10 @@ cloud.example.com nova With these two tables, you now have a good overview of what servers and services make up your cloud. - You can also use the Identity Service (keystone) to see what + You can also use the Identity service (keystone) to see what services are available in your cloud as well as what endpoints have been configured for the services. - Identity Service + Identity displaying services and endpoints with diff --git a/doc/openstack-ops/ch_ops_log_monitor.xml b/doc/openstack-ops/ch_ops_log_monitor.xml index 56c5b160..ca6a9534 100644 --- a/doc/openstack-ops/ch_ops_log_monitor.xml +++ b/doc/openstack-ops/ch_ops_log_monitor.xml @@ -209,7 +209,7 @@ 2013-02-25 21:05:51 17409 TRACE cinder In this example, cinder-volumes failed to start - and has provided a stack trace, since its volume backend has been unable + and has provided a stack trace, since its volume back end has been unable to set up the storage volume—probably because the LVM volume that is expected from the configuration does not exist. @@ -825,7 +825,7 @@ notification_driver=messagingv2 But how can you tell whether images are being successfully uploaded to the Image service? Maybe the disk that Image service is - storing the images on is full or the S3 backend is down. You could + storing the images on is full or the S3 back end is down. You could naturally check this by doing a quick image upload: diff --git a/doc/openstack-ops/ch_ops_maintenance.xml b/doc/openstack-ops/ch_ops_maintenance.xml index 7f61fc3e..2d140764 100644 --- a/doc/openstack-ops/ch_ops_maintenance.xml +++ b/doc/openstack-ops/ch_ops_maintenance.xml @@ -928,7 +928,7 @@ inner join nova.instances on cinder.volumes.instance_uuid=nova.instances.uuid deployed to your cloud: use an automated deployment system to bootstrap the bare-metal server with the operating system and then have a configuration-management system install and configure OpenStack Compute. - Once the Compute Service has been installed and configured in the same + Once the Compute service has been installed and configured in the same way as the other compute nodes, it automatically attaches itself to the cloud. The cloud controller notices the new node(s) and begins scheduling instances to launch there. diff --git a/doc/openstack-ops/ch_ops_network_troubleshooting.xml b/doc/openstack-ops/ch_ops_network_troubleshooting.xml index d27c9ef2..838727ec 100755 --- a/doc/openstack-ops/ch_ops_network_troubleshooting.xml +++ b/doc/openstack-ops/ch_ops_network_troubleshooting.xml @@ -145,9 +145,9 @@ Visualizing OpenStack Networking Service Traffic in the Cloud - The OpenStack Networking Service, neutron, has many more degrees of + OpenStack Networking has many more degrees of freedom than nova-network does because of its pluggable - backend. It can be configured with open source or vendor proprietary + back end. It can be configured with open source or vendor proprietary plug-ins that control software defined networking (SDN) hardware or plug-ins that use Linux native facilities on your hosts, such as Open vSwitch or Linux Bridge. @@ -164,8 +164,8 @@ various components involved however they are plumbed together in your environment. - For this example, we will use the Open vSwitch (OVS) backend. Other - backend plug-ins will have very different flow paths. OVS is the most + For this example, we will use the Open vSwitch (OVS) back end. Other + back-end plug-ins will have very different flow paths. OVS is the most popularly deployed network driver, according to the October 2013 OpenStack User Survey, with 50 percent more sites using it than the second place Linux Bridge driver. We'll describe each step in turn, with Troubleshooting Open vSwitch - Open vSwitch, as used in the previous OpenStack Networking Service + Open vSwitch, as used in the previous OpenStack Networking examples is a full-featured multilayer virtual switch licensed under the open source Apache 2.0 license. Full documentation can be found at the project's website. In diff --git a/doc/openstack-ops/ch_ops_projects_users.xml b/doc/openstack-ops/ch_ops_projects_users.xml index 4f8c32fb..caa24d24 100644 --- a/doc/openstack-ops/ch_ops_projects_users.xml +++ b/doc/openstack-ops/ch_ops_projects_users.xml @@ -20,9 +20,9 @@ While version 3 of the Identity API is available, the client tools do not yet implement those calls, and most OpenStack clouds are still implementing Identity API v2.0. - Identity Service + Identity - Identity Service API + Identity service API @@ -46,10 +46,10 @@ definition of - The initial implementation of the OpenStack Compute Service (nova) + The initial implementation of OpenStack Compute had its own authentication system and used the term project. When authentication moved into the OpenStack - Identity Service (keystone) project, it used the term + Identity (keystone) project, it used the term tenant to refer to a group of users. Because of this legacy, some of the OpenStack tools refer to projects and some refer to tenants. @@ -156,7 +156,7 @@ Using the command-line interface, you can manage quotas for the - OpenStack Compute Service and the Block Storage Service. + OpenStack Compute service and the Block Storage service. Typically, default values are changed because a tenant requires more than the OpenStack default of 10 volumes per tenant, or more than the @@ -217,12 +217,12 @@
Set Compute Service Quotas - As an administrative user, you can update the Compute Service + As an administrative user, you can update the Compute service quotas for an existing tenant, as well as update the quota defaults for a new tenant. Compute - Compute Service + Compute service See . @@ -593,7 +593,7 @@ Accept-Ranges: bytesSet Block Storage QuotasAs an administrative user, you can update the Block Storage - Service quotas for a tenant, as well as update the quota defaults for a + service quotas for a tenant, as well as update the quota defaults for a new tenant. See . Block Storage diff --git a/doc/openstack-ops/ch_ops_upgrades.xml b/doc/openstack-ops/ch_ops_upgrades.xml index 82bd9d59..497ea5d6 100644 --- a/doc/openstack-ops/ch_ops_upgrades.xml +++ b/doc/openstack-ops/ch_ops_upgrades.xml @@ -216,21 +216,20 @@ - Upgrade the OpenStack Identity Service - (keystone). + Upgrade OpenStack Identity. - Upgrade the OpenStack Image service (glance). + Upgrade the OpenStack Image service. - Upgrade OpenStack Compute (nova), including networking + Upgrade OpenStack Compute, including networking components. - Upgrade OpenStack Block Storage (cinder). + Upgrade OpenStack Block Storage. @@ -332,9 +331,8 @@ scheduler=havana Installation Guide and upgrading to the same architecture for Havana. All nodes should run Ubuntu 12.04 LTS. This section primarily addresses upgrading core OpenStack - services, such as the Identity Service (keystone), Image service - (glance), Compute (nova) including networking, Block Storage - (cinder), and the dashboard. upgrading Grizzly to Havana (Ubuntu) @@ -703,10 +701,9 @@ auth_uri = http://controller:5000 same architecture for Havana. All nodes should run Red Hat Enterprise Linux 6.4 or compatible derivatives. Newer minor releases should also work. This section primarily addresses - upgrading core OpenStack services, such as the Identity Service - (keystone), Image service (glance), Compute (nova) including - networking, Block Storage (cinder), and the dashboard. + upgrading core OpenStack services, such as the Identity, + Image service, Compute including networking, Block Storage, + and the dashboard. upgrading Grizzly to Havana (Red Hat) diff --git a/doc/openstack-ops/part_architecture.xml b/doc/openstack-ops/part_architecture.xml index 9dadda93..77319388 100644 --- a/doc/openstack-ops/part_architecture.xml +++ b/doc/openstack-ops/part_architecture.xml @@ -68,7 +68,7 @@ As shown, end users can interact through the dashboard, CLIs, and - APIs. All services authenticate through a common Identity Service, and + APIs. All services authenticate through a common Identity service, and individual services interact with each other through public APIs, except where privileged administrator commands are necessary. shows the most common, but not the diff --git a/doc/openstack-ops/section_arch_example-neutron.xml b/doc/openstack-ops/section_arch_example-neutron.xml index c1b58566..5ab631ba 100644 --- a/doc/openstack-ops/section_arch_example-neutron.xml +++ b/doc/openstack-ops/section_arch_example-neutron.xml @@ -101,19 +101,19 @@ - + - + - + @@ -176,7 +176,7 @@ MySQL - MySQL is used as the database backend for all databases in + MySQL is used as the database back end for all databases in the OpenStack environment. MySQL is the supported database of choice for Red Hat Enterprise Linux (and included in distribution); the database is open source, scalable, and handles @@ -863,7 +863,7 @@ role="keep-together">qpid_heartbeat = 10, configured to use a Gluster volume - from the storage layer as the backend for Block Storage, using the + from the storage layer as the back end for Block Storage, using the Gluster native client. - + - + @@ -321,8 +321,8 @@ your cloud will include Object Storage, you can easily add it as a back end. - We chose the SQL back end for the Identity Service - (keystone) over others, such as LDAP. This back end is simple + We chose the SQL back end for Identity + over others, such as LDAP. This back end is simple to install and is robust. The authors acknowledge that many installations want to bind with existing directory services and caution careful understanding of the Block Storage (cinder) is installed natively on external storage nodes and uses the LVM/iSCSI plug-in. Most Block - Storage Service plug-ins are tied to particular vendor products and + Storage plug-ins are tied to particular vendor products and implementations limiting their use to consumers of those hardware platforms, but LVM/iSCSI is robust and stable on commodity hardware. @@ -346,15 +346,15 @@
- Why not use the OpenStack Network Service (neutron)? + Why not use OpenStack Networking? - This example architecture does not use the OpenStack Network - Service (neutron), because it does not yet support multi-host networking + This example architecture does not use OpenStack Networking, + because it does not yet support multi-host networking and our organizations (university, government) have access to a large range of publicly-accessible IPv4 addresses. legacy networking (nova) - vs. OpenStack Network Service (neutron) + vs. OpenStack Networking (neutron)
Image service (glance) backendImage service back end GlusterFS
Identity Service (keystone) driverIdentity driver SQL
Block Storage Service (cinder) backendBlock Storage back end GlusterFS
Block Storage API, scheduler, and volume services are run on all diff --git a/doc/openstack-ops/section_arch_example-nova.xml b/doc/openstack-ops/section_arch_example-nova.xml index 2f2f4434..157e5e5e 100644 --- a/doc/openstack-ops/section_arch_example-nova.xml +++ b/doc/openstack-ops/section_arch_example-nova.xml @@ -142,13 +142,13 @@
Identity Service (keystone) driverIdentity (keystone) driver SQL
Block Storage Service (cinder) back endBlock Storage (cinder) back end LVM/iSCSI