diff --git a/doc/admin-guide-cloud/blockstorage/section_ts_eql_volume_size.xml b/doc/admin-guide-cloud/blockstorage/section_ts_eql_volume_size.xml index 91f83d4380..7c56c1a63f 100644 --- a/doc/admin-guide-cloud/blockstorage/section_ts_eql_volume_size.xml +++ b/doc/admin-guide-cloud/blockstorage/section_ts_eql_volume_size.xml @@ -13,10 +13,10 @@
Problem There is a discrepancy between both the actual volume size in EqualLogic (EQL) - storage and the image size in the Image Service, with what is reported + storage and the image size in the Image service, with what is reported OpenStack database. This could lead to confusion if a user is creating volumes from an image that was uploaded from an EQL volume (through the - Image Service). The image size is slightly larger than the target volume + Image service). The image size is slightly larger than the target volume size; this is because EQL size reporting accounts for additional storage used by EQL for internal volume metadata. To reproduce the issue follow the steps in the following procedure. @@ -95,7 +95,7 @@ ReplicationReserveSpace: 0MB +---------------------+---------------------------------------+ - When you uploaded the volume in the previous step, the Image Service + When you uploaded the volume in the previous step, the Image service reported the volume's size as 1 (GB). However, when using glance image-list to list the image, the displayed size is 1085276160 bytes, or roughly 1.01 GB: @@ -122,7 +122,7 @@ ReplicationReserveSpace: 0MB 3020a21d-ba37-4495-8899-07fc201161b9 in this example) as the source. Set the target volume size to 1 GB; this is the size reported by the cinder tool when you uploaded the volume to - the Image Service: + the Image service: $ cinder create --display-name volume2 \ --image-id 3020a21d-ba37-4495-8899-07fc201161b9 1 ERROR: Invalid input received: Size of specified image 2 is larger diff --git a/doc/admin-guide-cloud/ch_compute.xml b/doc/admin-guide-cloud/ch_compute.xml index ce8be02758..bd53ae1fc9 100644 --- a/doc/admin-guide-cloud/ch_compute.xml +++ b/doc/admin-guide-cloud/ch_compute.xml @@ -338,7 +338,7 @@
Building blocks In OpenStack the base operating system is usually copied - from an image stored in the OpenStack Image Service. This + from an image stored in the OpenStack Image service. This is the most common case and results in an ephemeral instance that starts from a known template state and loses all accumulated states on virtual machine deletion. It is diff --git a/doc/admin-guide-cloud/ch_database.xml b/doc/admin-guide-cloud/ch_database.xml index b85f14d473..1c42964421 100644 --- a/doc/admin-guide-cloud/ch_database.xml +++ b/doc/admin-guide-cloud/ch_database.xml @@ -30,8 +30,8 @@ trove_auth_url = http://controller:35357/v2.0This example assumes you have created a MySQL 5.5 image called mysql-5.5.qcow2. - Register image with Image Service - You need to register your guest image with the Image Service. + Register image with Image service + You need to register your guest image with the Image service. In this example, you use the glance image-create command to register a mysql-5.5.qcow2 image. $ glance image-create --name mysql-5.5 --disk-format qcow2 --container-format bare --is-public True < mysql-5.5.qcow2 +------------------+--------------------------------------+ diff --git a/doc/admin-guide-cloud/compute/section_compute-image-mgt.xml b/doc/admin-guide-cloud/compute/section_compute-image-mgt.xml index 0ed09e8344..a1b5d60f7d 100644 --- a/doc/admin-guide-cloud/compute/section_compute-image-mgt.xml +++ b/doc/admin-guide-cloud/compute/section_compute-image-mgt.xml @@ -5,7 +5,7 @@ version="5.0" xml:id="section_image-mgmt"> Image management - The OpenStack Image Service discovers, registers, and + The OpenStack Image service discovers, registers, and retrieves virtual machine images. The service also includes a RESTful API that allows you to query VM image metadata and retrieve the actual image with HTTP requests. For more @@ -14,25 +14,25 @@ >OpenStack API Complete Reference and the Python API. - The OpenStack Image Service can be controlled using a + The OpenStack Image service can be controlled using a command-line tool. For more information about using the OpenStack Image command-line tool, see the Manage Images section in the OpenStack End User Guide. Virtual images that have been made available through the - Image Service can be stored in a variety of ways. In order to + Image service can be stored in a variety of ways. In order to use these services, you must have a working installation of - the Image Service, with a working endpoint, and users that + the Image service, with a working endpoint, and users that have been created in OpenStack Identity. Additionally, you must meet the environment variables required by the Compute - and Image Service clients. - The Image Service supports these back-end stores: + and Image service clients. + The Image service supports these back-end stores: File system - The OpenStack Image Service stores virtual + The OpenStack Image service stores virtual machine images in the file system back end by default. This simple back end writes image files to the local file system. @@ -54,7 +54,7 @@ HTTP - OpenStack Image Service can read virtual machine + OpenStack Image service can read virtual machine images that are available on the Internet using HTTP. This store is read only. diff --git a/doc/admin-guide-cloud/compute/section_compute-images-instances.xml b/doc/admin-guide-cloud/compute/section_compute-images-instances.xml index c3efe16aa6..549b6bb194 100644 --- a/doc/admin-guide-cloud/compute/section_compute-images-instances.xml +++ b/doc/admin-guide-cloud/compute/section_compute-images-instances.xml @@ -4,7 +4,7 @@ xml:id="section_compute-images-and-instances"> Images and instances Disk images provide templates for virtual machine file systems. The - Image Service controls storage and management of images. + Image service controls storage and management of images. Instances are the individual virtual machines that run on physical compute nodes. Users can launch any number of instances from the same image. Each launched instance runs from a copy of the base image so that @@ -28,7 +28,7 @@ For more information about image configuration options, see the - Image Services section of the OpenStack + Image services section of the OpenStack Configuration Reference. @@ -46,7 +46,7 @@ service, which provides persistent block storage, instead of the ephemeral storage provided by the selected instance flavor. This diagram shows the system state prior to launching an instance. - The image store, fronted by the Image Service (glance) has a number of + The image store, fronted by the Image service (glance) has a number of predefined images. Inside the cloud, a compute node contains the available vCPU, memory, and local disk resources. Additionally, the cinder-volume service provides diff --git a/doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml b/doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml index 95f368993a..9316503db3 100644 --- a/doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml +++ b/doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml @@ -6,7 +6,7 @@ xml:id="section_compute-instance-building-blocks"> Instance building blocks In OpenStack, the base operating system is usually copied from an - image stored in the OpenStack Image Service. This results in an + image stored in the OpenStack Image service. This results in an ephemeral instance that starts from a known template state and loses all accumulated states on shutdown. You can also put an operating system on a persistent volume in diff --git a/doc/admin-guide-cloud/compute/section_compute-system-admin.xml b/doc/admin-guide-cloud/compute/section_compute-system-admin.xml index f055a2e75b..25dc4b2e60 100644 --- a/doc/admin-guide-cloud/compute/section_compute-system-admin.xml +++ b/doc/admin-guide-cloud/compute/section_compute-system-admin.xml @@ -41,7 +41,7 @@ nova-objectstore: a simple file-based storage system for images that replicates most - of the S3 API. It can be replaced with OpenStack Image Service and + of the S3 API. It can be replaced with OpenStack Image service and either a simple image manager or OpenStack Object Storage as the virtual machine image storage facility. It must exist on the same node as nova-compute. @@ -271,7 +271,7 @@ qualname = nova syslog. This is useful if you want to use rsyslog to forward logs to a remote machine. Separately configure the Compute service (nova), the Identity - service (keystone), the Image Service (glance), and, if you are + service (keystone), the Image service (glance), and, if you are using it, the Block Storage service (cinder) to send log messages to syslog. Open these configuration files: diff --git a/doc/admin-guide-cloud/image/section_glance-nova-image-download.xml b/doc/admin-guide-cloud/image/section_glance-nova-image-download.xml index 3e74c12593..fa7297d6cd 100644 --- a/doc/admin-guide-cloud/image/section_glance-nova-image-download.xml +++ b/doc/admin-guide-cloud/image/section_glance-nova-image-download.xml @@ -13,7 +13,7 @@ Prior to starting a virtual machine, the virtual machine image used must be transferred to the compute node from the Image Service. How this works can change depending on the settings - chosen for the compute node and the Image Service. + chosen for the compute node and the Image service. Typically, the Compute service will use the image identifier @@ -21,8 +21,8 @@ Image API. Though images are not stored in glance—rather in a back end, which could be Object Storage, a filesystem or any other supported method—the connection is made from the compute node - to the Image Service and the image is transferred over this - connection. The Image Service streams the image from the back end to the + to the Image service and the image is transferred over this + connection. The Image service streams the image from the back end to the compute node. @@ -34,7 +34,7 @@ Certain back ends support a more direct method, where on request - the Image Service will return a URL that can be used to + the Image service will return a URL that can be used to download the image directly from the back-end store. Currently the only store to support the direct download approach is the filesystem store. It can be configured using the diff --git a/doc/admin-guide-cloud/networking/section_networking_arch.xml b/doc/admin-guide-cloud/networking/section_networking_arch.xml index 5d0ee4218e..f2f5804dd4 100644 --- a/doc/admin-guide-cloud/networking/section_networking_arch.xml +++ b/doc/admin-guide-cloud/networking/section_networking_arch.xml @@ -11,7 +11,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 + as Compute, Image service, Identity, or the Dashboard. Like those components, a deployment of Networking often involves deploying several services to a variety of hosts. The Networking server uses the - OpenStack Image Service + OpenStack Image service image.update image.upload image.delete @@ -96,7 +96,7 @@ The required configuration for Image service can be found in the - Configure the Image Service for Telemetry section section + Configure the Image service for Telemetry section section in the OpenStack Installation Guide. diff --git a/doc/admin-guide-cloud/telemetry/section_telemetry-data-retrieval.xml b/doc/admin-guide-cloud/telemetry/section_telemetry-data-retrieval.xml index 44f6c47e73..32d69a888e 100644 --- a/doc/admin-guide-cloud/telemetry/section_telemetry-data-retrieval.xml +++ b/doc/admin-guide-cloud/telemetry/section_telemetry-data-retrieval.xml @@ -243,7 +243,7 @@ The Telemetry module captures the user-visible resource usage data. Therefore the database will not contain any data without the existence of these resources, - like VM images in the OpenStack Image Service. + like VM images in the OpenStack Image service. Similarly to other OpenStack command line clients, the ceilometer client uses OpenStack Identity for authentication. The proper credentials and diff --git a/doc/admin-guide-cloud/telemetry/section_telemetry-measurements.xml b/doc/admin-guide-cloud/telemetry/section_telemetry-measurements.xml index e6a6870995..ba3b8cec39 100644 --- a/doc/admin-guide-cloud/telemetry/section_telemetry-measurements.xml +++ b/doc/admin-guide-cloud/telemetry/section_telemetry-measurements.xml @@ -224,8 +224,8 @@
- OpenStack Image Service - The following meters are collected for OpenStack Image Service: + OpenStack Image service + The following meters are collected for OpenStack Image service:
diff --git a/doc/arch-design/compute_focus/section_architecture_compute_focus.xml b/doc/arch-design/compute_focus/section_architecture_compute_focus.xml index 658e0ff82e..52a29f125d 100644 --- a/doc/arch-design/compute_focus/section_architecture_compute_focus.xml +++ b/doc/arch-design/compute_focus/section_architecture_compute_focus.xml @@ -472,7 +472,7 @@ OpenStack components The selection of which OpenStack components will actually be included in the design and deployed has significant impact. There are - certain components that will always be present, (Compute and Image Service, for + certain components that will always be present, (Compute and Image service, for example) yet there are other services that might not need to be present. For example, a certain design may not require the Orchestration module. Omitting Heat would not typically have a significant impact on the diff --git a/doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml b/doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml index c8fb3ec83f..535b681b5e 100644 --- a/doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml +++ b/doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml @@ -114,7 +114,7 @@ the addresses were assigned to.
Storage architecture - The OpenStack Image Service is deployed in the API cell and + The OpenStack Image service is deployed in the API cell and configured to expose version 1 (V1) of the API. As a result the image registry is also required. The storage back end in use is a 3 PB Ceph cluster. diff --git a/doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml b/doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml index e38a26a2ca..d816227ce7 100644 --- a/doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml +++ b/doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml @@ -367,7 +367,7 @@ OpenStack Compute (nova) - OpenStack Image Service (glance) + OpenStack Image service (glance) OpenStack Identity (keystone) diff --git a/doc/arch-design/generalpurpose/section_architecture_general_purpose.xml b/doc/arch-design/generalpurpose/section_architecture_general_purpose.xml index 207fe02cf7..bfa470b674 100644 --- a/doc/arch-design/generalpurpose/section_architecture_general_purpose.xml +++ b/doc/arch-design/generalpurpose/section_architecture_general_purpose.xml @@ -667,7 +667,7 @@ OpenStack components Selecting which OpenStack components are included in the overall design can have a significant impact. Some OpenStack components, like - compute and Image Service, are required in every architecture. Other + compute and Image service, are required in every architecture. Other components, like Orchestration, are not always required. Excluding certain OpenStack components can limit or constrain the functionality of other components. For example, if the architecture includes diff --git a/doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml b/doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml index add9374164..b6b8b5e6b8 100644 --- a/doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml +++ b/doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml @@ -77,7 +77,7 @@ archiving. Additional capabilities can be realized by moving static web content to be served from OpenStack Object - Storage containers, and backing the OpenStack Image Service + Storage containers, and backing the OpenStack Image service with OpenStack Object Storage. diff --git a/doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml b/doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml index c2d683d657..7c2527adca 100644 --- a/doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml +++ b/doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml @@ -517,7 +517,7 @@ (neutron) - OpenStack Image Service + OpenStack Image service (glance) diff --git a/doc/arch-design/multi_site/section_operational_considerations_multi_site.xml b/doc/arch-design/multi_site/section_operational_considerations_multi_site.xml index e8e6c9a721..60614b5aa5 100644 --- a/doc/arch-design/multi_site/section_operational_considerations_multi_site.xml +++ b/doc/arch-design/multi_site/section_operational_considerations_multi_site.xml @@ -85,7 +85,7 @@ (keystone). - Upgrade the OpenStack Image Service (glance). + Upgrade the OpenStack Image service (glance). Upgrade OpenStack Compute (nova), including @@ -106,7 +106,7 @@ (keystone) deployment. - Upgrade the OpenStack Image Service (glance) at each + Upgrade the OpenStack Image service (glance) at each site. diff --git a/doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml b/doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml index a0b639917d..e4657dd871 100644 --- a/doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml +++ b/doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml @@ -109,7 +109,7 @@ OpenStack Controller services running, Networking, dashboard, Block Storage and Compute running locally in each of the three regions. The other services, - Identity, Orchestration, Telemetry, Image Service and + Identity, Orchestration, Telemetry, Image service and Object Storage can be installed centrally—with nodes in each of the region providing a redundant OpenStack Controller plane @@ -176,7 +176,7 @@ external tools were not needed. OpenStack Object Storage is used here to serve as a back end for - the Image Service since it is the most suitable solution for a + the Image service since it is the most suitable solution for a globally distributed storage solution—with its own replication mechanism. Home grown solutions could also have been used including the handling of replication—but were not diff --git a/doc/arch-design/multi_site/section_tech_considerations_multi_site.xml b/doc/arch-design/multi_site/section_tech_considerations_multi_site.xml index e1ea9ca2f0..253d5fd036 100644 --- a/doc/arch-design/multi_site/section_tech_considerations_multi_site.xml +++ b/doc/arch-design/multi_site/section_tech_considerations_multi_site.xml @@ -170,7 +170,7 @@ Most OpenStack installations require a bare minimum set of pieces to function. These include the OpenStack Identity (keystone) for authentication, OpenStack Compute - (nova) for compute, OpenStack Image Service (glance) for image + (nova) for compute, OpenStack Image service (glance) for image storage, OpenStack Networking (neutron) for networking, and potentially an object store in the form of OpenStack Object Storage (swift). Bringing multi-site into play also demands extra diff --git a/doc/arch-design/multi_site/section_user_requirements_multi_site.xml b/doc/arch-design/multi_site/section_user_requirements_multi_site.xml index 6accc12f1c..7ef50ddbdc 100644 --- a/doc/arch-design/multi_site/section_user_requirements_multi_site.xml +++ b/doc/arch-design/multi_site/section_user_requirements_multi_site.xml @@ -74,7 +74,7 @@ It is essential that the deployment of instances is consistent across the different sites. This needs to be built into the infrastructure. If the OpenStack Object Storage is used as - a back end for the Image Service, it is possible to create repositories of + a back end for the Image service, it is possible to create repositories of consistent images across multiple sites. Having central endpoints with multiple storage nodes allows consistent centralized storage for each and every site. diff --git a/doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml b/doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml index 9225cfa8fa..cf674499d3 100644 --- a/doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml +++ b/doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml @@ -67,7 +67,7 @@ - Beyond the normal Identity, Compute, Image Service and Object + Beyond the normal Identity, Compute, Image service and Object Storage components, the Orchestration module is a recommended component to handle properly scaling the workloads to adjust to demand. Due to the requirement for auto-scaling, diff --git a/doc/arch-design/specialized/section_hardware_specialized.xml b/doc/arch-design/specialized/section_hardware_specialized.xml index 67a65104cb..675cf8457a 100644 --- a/doc/arch-design/specialized/section_hardware_specialized.xml +++ b/doc/arch-design/specialized/section_hardware_specialized.xml @@ -25,13 +25,13 @@
Solutions To provide cryptography offloading to a set of - instances, you can use Image Service configuration + instances, you can use Image service configuration options to assign the cryptography chip to a device node in the guest. The OpenStack Command Line Reference contains further information on configuring this solution in the chapter - Image Service property keys, but it allows all + Image service property keys, but it allows all guests using the configured images to access the hypervisor cryptography device. If you require direct access to a specific device, PCI diff --git a/doc/arch-design/specialized/section_multi_hypervisor_specialized.xml b/doc/arch-design/specialized/section_multi_hypervisor_specialized.xml index c747fcf3b9..5acf4096b0 100644 --- a/doc/arch-design/specialized/section_multi_hypervisor_specialized.xml +++ b/doc/arch-design/specialized/section_multi_hypervisor_specialized.xml @@ -30,16 +30,16 @@ workloads that must run on ESXi can target those hypervisors, but the rest target the KVM hypervisors. - Images in the OpenStack Image Service have particular + Images in the OpenStack Image service have particular hypervisor metadata attached so that when a user requests a certain image, the instance spawns on the relevant aggregate. Images for ESXi use the VMDK format. You can convert QEMU disk images to VMDK, VMFS Flat Disks, which includes thin, thick, zeroed-thick, and eager-zeroed-thick. Note that after you export a VMFS thin disk from VMFS to a - non-VMFS location, for example the OpenStack Image Service, it + non-VMFS location, for example the OpenStack Image service, it becomes a preallocated flat disk. This impacts the transfer - time from the OpenStack Image Service to the data store as it + time from the OpenStack Image service to the data store as it requires moving the full preallocated flat disk rather than the thin disk. This example has the additional complication that, rather diff --git a/doc/arch-design/storage_focus/section_architecture_storage_focus.xml b/doc/arch-design/storage_focus/section_architecture_storage_focus.xml index 4defe8f99d..92e79d04ef 100644 --- a/doc/arch-design/storage_focus/section_architecture_storage_focus.xml +++ b/doc/arch-design/storage_focus/section_architecture_storage_focus.xml @@ -488,7 +488,7 @@ OpenStack components Which OpenStack components you choose can have a significant impact on the overall design. While there are certain - components that are always present, Compute and Image Service, for + components that are always present, Compute and Image service, for example, there are other services that may not need to be present. As an example, a certain design may not require the Orchestration module. Omitting Orchestration would not typically have a @@ -519,7 +519,7 @@ OpenStack Block Storage (cinder) - OpenStack Image Service (glance) + OpenStack Image service (glance) OpenStack Networking (neutron) or legacy networking (nova-network) diff --git a/doc/cli-reference/bk-cli-reference.xml b/doc/cli-reference/bk-cli-reference.xml index 16951dda0e..c1f5b0a80d 100644 --- a/doc/cli-reference/bk-cli-reference.xml +++ b/doc/cli-reference/bk-cli-reference.xml @@ -75,7 +75,7 @@ For the Icehouse release, updated documentation for clients, add trove options, document neutron-debug, - document Image Service property + document Image service property keys. diff --git a/doc/cli-reference/ch_cli_glance_property_keys.xml b/doc/cli-reference/ch_cli_glance_property_keys.xml index 70172308d1..a77b50f3e0 100644 --- a/doc/cli-reference/ch_cli_glance_property_keys.xml +++ b/doc/cli-reference/ch_cli_glance_property_keys.xml @@ -9,7 +9,7 @@ version="5.0" xml:id="chapter_cli-glance-property"> - Image Service property keys + Image service property keys The following keys, together with the components to which they are specific, can be used with the option for both the glance image-update and glance image-create commands. For @@ -138,7 +138,7 @@ All kernel_id - The ID of an image stored in the Image Service that should be used as the kernel + The ID of an image stored in the Image service that should be used as the kernel when booting an AMI-style image. Valid image ID @@ -209,7 +209,7 @@ All ramdisk_id - The ID of image stored in the Image Service that should be used as the ramdisk + The ID of image stored in the Image service that should be used as the ramdisk when booting an AMI-style image. Valid image ID diff --git a/doc/common/app_support.xml b/doc/common/app_support.xml index 14b84ecee7..560595efe5 100644 --- a/doc/common/app_support.xml +++ b/doc/common/app_support.xml @@ -263,7 +263,7 @@ Bugs: OpenStack Image Service + >Bugs: OpenStack Image service (glance) diff --git a/doc/common/ch_getstart.xml b/doc/common/ch_getstart.xml index 43df55681c..3f45b9b280 100644 --- a/doc/common/ch_getstart.xml +++ b/doc/common/ch_getstart.xml @@ -126,7 +126,7 @@ Image Service + >Image service - You can upload images through the glance client or the Image Service + You can upload images through the glance client or the Image service API. Besides, you can use the nova client for the image management. The latter provides mechanisms to list and delete images, set and delete image metadata, and create images of a running instance of snapshot and backup types. @@ -101,7 +101,7 @@ - After you restart the Image Service, you can use the following syntax to view the image's location information: + After you restart the Image service, you can use the following syntax to view the image's location information: $ glance --os-image-api-version 2 image-show imageID For example, using the image ID shown above, you would issue the command as follows: @@ -117,7 +117,7 @@ The following table lists the optional arguments that you can use with the create and update commands to modify image - properties. For more information, refer to Image Service chapter in the OpenStack Command-Line Interface Reference. @@ -411,7 +411,7 @@
Troubleshoot image creation - If you encounter problems in creating an image in Image Service or Compute, the + If you encounter problems in creating an image in Image service or Compute, the following information may help you troubleshoot the creation process. diff --git a/doc/common/section_cli_install.xml b/doc/common/section_cli_install.xml index 38b3cb22cd..3825993fee 100644 --- a/doc/common/section_cli_install.xml +++ b/doc/common/section_cli_install.xml @@ -178,7 +178,7 @@ and extensions - glance - Image Service + glance - Image service API diff --git a/doc/common/section_cli_nova_manage_images.xml b/doc/common/section_cli_nova_manage_images.xml index e920a87851..d198d01597 100644 --- a/doc/common/section_cli_nova_manage_images.xml +++ b/doc/common/section_cli_nova_manage_images.xml @@ -52,7 +52,7 @@ through the Block Storage service. - No data is uploaded to the Image Service. + No data is uploaded to the Image service. You can find information about the snapshot in the properties of the diff --git a/doc/common/section_cli_overview.xml b/doc/common/section_cli_overview.xml index 440168bac0..9237b0ad36 100644 --- a/doc/common/section_cli_overview.xml +++ b/doc/common/section_cli_overview.xml @@ -69,7 +69,7 @@ Create and manage users, tenants, roles, endpoints, and credentials. - Image Service + Image service glance python-glanceclient Create and manage images. diff --git a/doc/common/section_dashboard_launch_instances_from_image.xml b/doc/common/section_dashboard_launch_instances_from_image.xml index a64fd58e17..d8c8778b84 100644 --- a/doc/common/section_dashboard_launch_instances_from_image.xml +++ b/doc/common/section_dashboard_launch_instances_from_image.xml @@ -9,7 +9,7 @@ Instances are virtual machines that run inside the cloud. You can launch an instance directly from one of the - available OpenStack images. The OpenStack Image Service + available OpenStack images. The OpenStack Image service provides a pool of images that are accessible to members of different projects. When you launch an instance from an image, OpenStack creates a local copy of the image on the respective @@ -91,7 +91,7 @@ Click the Images & Snapshot category. The dashboard shows the images that have been - uploaded to OpenStack Image Service and are available + uploaded to OpenStack Image service and are available for this project. diff --git a/doc/common/section_getstart_compute.xml b/doc/common/section_getstart_compute.xml index 59796926bc..fa91feaf3b 100644 --- a/doc/common/section_getstart_compute.xml +++ b/doc/common/section_getstart_compute.xml @@ -10,7 +10,7 @@ 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 + authentication, 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 @@ -197,12 +197,12 @@ daemon An S3 interface for registering images with the - OpenStack Image Service. Used primarily for installations + OpenStack Image service. Used primarily for installations that must support euca2ools. The euca2ools tools talk to nova-objectstore in S3 language, and nova-objectstore - translates S3 requests into Image Service requests. + translates S3 requests into Image service requests. diff --git a/doc/common/section_getstart_image.xml b/doc/common/section_getstart_image.xml index db2a226f93..98286a6f35 100644 --- a/doc/common/section_getstart_image.xml +++ b/doc/common/section_getstart_image.xml @@ -4,18 +4,18 @@ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="image-service-overview"> - OpenStack Image Service - The OpenStack Image Service is central to Infrastructure-as-a-Service (IaaS) + OpenStack Image service + The OpenStack Image service is central to Infrastructure-as-a-Service (IaaS) as shown in . 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 repository types, including OpenStack Object Storage. - 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 + The OpenStack Image service includes the following components: @@ -29,7 +29,7 @@ images. Metadata includes items such as size and type. Security note The registry is a private internal service meant for use - by OpenStack Image Service. Do not disclose it to + by OpenStack Image service. Do not disclose it to users. diff --git a/doc/common/section_keystone-concepts-user-management.xml b/doc/common/section_keystone-concepts-user-management.xml index 20c2065c2d..6d0975c999 100644 --- a/doc/common/section_keystone-concepts-user-management.xml +++ b/doc/common/section_keystone-concepts-user-management.xml @@ -47,7 +47,7 @@ $ openstack role create compute-user Individual services, such as Compute and the - Image Service, assign meaning to roles. In the + Image service, assign meaning to roles. In the Identity Service, a role is simply a name. @@ -87,11 +87,11 @@ /etc/nova/policy.json specifies the access policy for the Compute service, /etc/glance/policy.json specifies the - access policy for the Image Service, and + access policy for the Image service, and /etc/keystone/policy.json specifies the access policy for the Identity Service. The default policy.json files in the - Compute, Identity, and Image Service recognize only the + Compute, Identity, and Image service recognize only the admin role: all operations that do not require the admin role are accessible by any user that has any role in a tenant. diff --git a/doc/common/section_keystone-concepts.xml b/doc/common/section_keystone-concepts.xml index 568db36bc9..cb881d86cb 100644 --- a/doc/common/section_keystone-concepts.xml +++ b/doc/common/section_keystone-concepts.xml @@ -88,7 +88,7 @@ Service An OpenStack service, such as Compute (nova), - Object Storage (swift), or Image Service (glance). + Object Storage (swift), or Image service (glance). It provides one or more endpoints in which users can access resources and perform operations. diff --git a/doc/common/section_objectstorage_tenant-specific-image-storage.xml b/doc/common/section_objectstorage_tenant-specific-image-storage.xml index a15e305a43..2057494200 100644 --- a/doc/common/section_objectstorage_tenant-specific-image-storage.xml +++ b/doc/common/section_objectstorage_tenant-specific-image-storage.xml @@ -8,9 +8,9 @@ Storage For some deployers, it is not ideal to store all images in one place to enable all tenants and users to access them. You - can configure the Image Service to store image data in + can configure the Image service to store image data in tenant-specific image locations. Then, only the following - tenants can use the Image Service to access the created image: + tenants can use the Image service to access the created image: The tenant who owns the image @@ -41,7 +41,7 @@ Specify a list of tenant IDs that can grant read and write access to all Object Storage containers that are created by the - Image Service. + Image service. diff --git a/doc/common/section_storage-concepts.xml b/doc/common/section_storage-concepts.xml index f556664af0..9a5f231836 100644 --- a/doc/common/section_storage-concepts.xml +++ b/doc/common/section_storage-concepts.xml @@ -71,7 +71,7 @@ easily and avoid a central point of failure. - The OpenStack Image Service is used to manage + The OpenStack Image service is used to manage the virtual machine images in an OpenStack cluster, not store them. It provides an abstraction to different methods for storage - a bridge to the storage, not the storage diff --git a/doc/config-reference/ch_computeconfigure.xml b/doc/config-reference/ch_computeconfigure.xml index 1dfd329626..17e6c5ab83 100644 --- a/doc/config-reference/ch_computeconfigure.xml +++ b/doc/config-reference/ch_computeconfigure.xml @@ -24,7 +24,7 @@ directory. - Related Image Service and Identity service management + Related Image service and Identity service management configuration files. diff --git a/doc/config-reference/ch_config-overview.xml b/doc/config-reference/ch_config-overview.xml index ac21c5b7d5..1d72c36823 100644 --- a/doc/config-reference/ch_config-overview.xml +++ b/doc/config-reference/ch_config-overview.xml @@ -19,7 +19,7 @@ OpenStack Dashboard Database service OpenStack Identity - OpenStack Image Service + OpenStack Image service OpenStack Networking OpenStack Object Storage Telemetry diff --git a/doc/config-reference/ch_imageservice.xml b/doc/config-reference/ch_imageservice.xml index 0c1ddd4c9e..825684cd4d 100644 --- a/doc/config-reference/ch_imageservice.xml +++ b/doc/config-reference/ch_imageservice.xml @@ -4,11 +4,11 @@ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="ch_configuring-openstack-image-service"> - Image Service + Image service Compute relies on an external image service to store virtual machine images and maintain a catalog of available images. By - default, Compute is configured to use the OpenStack Image Service - (Glance), which is currently the only supported image + default, Compute is configured to use the OpenStack Image service + (glance), which is currently the only supported image service. @@ -21,7 +21,7 @@ settings documented in and . - You can modify many options in the OpenStack Image Service. + You can modify many options in the OpenStack Image service. The following tables provide a comprehensive list. diff --git a/doc/config-reference/compute/section_hypervisor_hyper-v.xml b/doc/config-reference/compute/section_hypervisor_hyper-v.xml index 6f2bb054fd..b9bedcf9cd 100644 --- a/doc/config-reference/compute/section_hypervisor_hyper-v.xml +++ b/doc/config-reference/compute/section_hypervisor_hyper-v.xml @@ -97,7 +97,7 @@ The target hosts checks if the image to be migrated requires a base VHD and pulls it from the - Image Service if not already available on the target + Image service if not already available on the target host. diff --git a/doc/config-reference/compute/section_hypervisor_vmware.xml b/doc/config-reference/compute/section_hypervisor_vmware.xml index e9a368c276..c8198a56fc 100644 --- a/doc/config-reference/compute/section_hypervisor_vmware.xml +++ b/doc/config-reference/compute/section_hypervisor_vmware.xml @@ -52,9 +52,9 @@ interacts with the vCenter APIs to select an appropriate ESX host within the cluster. Internally, vCenter uses DRS for placement. The VMware vCenter driver also interacts with the OpenStack - Image Service to copy VMDK images from the Image Service back - end store. The dotted line in the figure represents VMDK images - being copied from the OpenStack Image Service to the vSphere + Image service to copy VMDK images from the Image service back-end + store. The dotted line in the figure represents VMDK images + being copied from the OpenStack Image service to the vSphere data store. VMDK images are cached in the data store so the copy operation is only required the first time that the VMDK image is used. @@ -636,29 +636,29 @@ datastore_regex=<optional datastore regex> environment. It is also possible to convert other formats, such as qcow2, to the VMDK format using the utility. After a VMDK disk is available, load it into the - OpenStack Image Service. Then, you can use it with the VMware + OpenStack Image service. Then, you can use it with the VMware vCenter driver. The following sections provide additional details on the supported disks and the commands used for conversion and upload.
Supported image types - Upload images to the OpenStack Image Service in VMDK + Upload images to the OpenStack Image service in VMDK format. The following VMDK disk types are supported: VMFS Flat Disks (includes thin, thick, zeroedthick, and eagerzeroedthick). Note that once a VMFS thin disk is exported from VMFS to a - non-VMFS location, like the OpenStack Image Service, it + non-VMFS location, like the OpenStack Image service, it becomes a preallocated flat disk. This impacts the - transfer time from the OpenStack Image Service to the data + transfer time from the OpenStack Image service to the data store when the full preallocated flat disk, rather than the thin disk, must be transferred. Monolithic Sparse disks. Sparse disks get imported from the - OpenStack Image Service into ESX as thin provisioned + OpenStack Image service into ESX as thin provisioned disks. Monolithic Sparse disks can be obtained from VMware Fusion or can be created by converting from other virtual disk formats using the qemu-img @@ -669,7 +669,7 @@ datastore_regex=<optional datastore regex> property that applies to each of the supported VMDK disk types: - + @@ -699,7 +699,7 @@ datastore_regex=<optional datastore regex>
OpenStack Image Service disk type settingsOpenStack Image service disk type settings
vmware_disktype property
The property is set when an - image is loaded into the OpenStack Image Service. For example, + image is loaded into the OpenStack Image service. For example, the following command creates a Monolithic Sparse image by setting to sparse: @@ -794,7 +794,7 @@ trusty-server-cloudimg-amd64-disk1.vmdk To avoid the conversion step (at the cost of longer download times) consider converting sparse disks to thin provisioned or preallocated disks before loading them into the - OpenStack Image Service. + OpenStack Image service. Use one of the following tools to pre-convert sparse disks. @@ -848,20 +848,20 @@ trusty-server-cloudimg-amd64-disk1.vmdk The ESX hypervisor requires a copy of the VMDK file in order to boot up a virtual machine. As a result, the vCenter OpenStack Compute driver must download the VMDK via HTTP from - the OpenStack Image Service to a data store that is visible to + the OpenStack Image service to a data store that is visible to the hypervisor. To optimize this process, the first time a VMDK file is used, it gets cached in the data store. A cached image is stored in a folder named after the image ID. Subsequent virtual machines that need the VMDK use the cached version and don't have to copy the file again from the - OpenStack Image Service. + OpenStack Image service. Even with a cached VMDK, there is still a copy operation from the cache location to the hypervisor file directory in the shared data store. To avoid this copy, boot the image in linked_clone mode. To learn how to enable this mode, see . You can also use the vmware_linked_clone property in the OpenStack - Image Service to + Image service to override the linked_clone mode on a per-image basis. If multiple compute nodes are running on the same host, diff --git a/doc/config-reference/compute/section_introduction-to-xen.xml b/doc/config-reference/compute/section_introduction-to-xen.xml index 815fa7216a..347ac34be6 100644 --- a/doc/config-reference/compute/section_introduction-to-xen.xml +++ b/doc/config-reference/compute/section_introduction-to-xen.xml @@ -177,7 +177,7 @@ communication. Please note that the VM images are downloaded by the XenAPI plug-ins, so make sure that the OpenStack - Image Service is accessible through this + Image service is accessible through this network. It usually means binding those services to the management interface. diff --git a/doc/config-reference/compute/section_nova-conf.xml b/doc/config-reference/compute/section_nova-conf.xml index 7632b6b328..ce09ff9f22 100644 --- a/doc/config-reference/compute/section_nova-conf.xml +++ b/doc/config-reference/compute/section_nova-conf.xml @@ -76,7 +76,7 @@ [glance] - Configures how to access the Image Service. + Configures how to access the Image service. diff --git a/doc/config-reference/image-service/section_image-service-ISO-support.xml b/doc/config-reference/image-service/section_image-service-ISO-support.xml index a13e3d1997..4eef3620ba 100644 --- a/doc/config-reference/image-service/section_image-service-ISO-support.xml +++ b/doc/config-reference/image-service/section_image-service-ISO-support.xml @@ -5,24 +5,24 @@ version="5.0" xml:id="iso-support"> Support for ISO images - You can load ISO images into the Image Service. You can + You can load ISO images into the Image service. You can subsequently boot an ISO image using Compute. - To load an ISO image to an Image Service data + <title>To load an ISO image to an Image service data store Obtain the ISO image. For example, ubuntu-13.04-server-amd64.iso. - In the Image Service, run the following + In the Image service, run the following command: $ glance image-create --name ubuntu.iso \ --is-public True --container-format bare \ --disk-format iso < ubuntu-13.04-server-amd64.iso In this command, ubuntu.iso is the name for the ISO image after it is loaded to the - Image Service, and + Image service, and ubuntu-13.04-server-amd64.iso is the name of the source ISO image. diff --git a/doc/config-reference/image-service/section_image-service-api.xml b/doc/config-reference/image-service/section_image-service-api.xml index 6c14ef9708..8a9b8f4661 100644 --- a/doc/config-reference/image-service/section_image-service-api.xml +++ b/doc/config-reference/image-service/section_image-service-api.xml @@ -4,7 +4,7 @@ version="5.0" xml:id="image-configuring-api"> Configure the API - The Image Service has two APIs: the user-facing API, and + The Image service has two APIs: the user-facing API, and the registry API, which is for internal requests that require access to the database. Both of the APIs currently have two major versions, v1 and v2. diff --git a/doc/config-reference/image-service/section_image-service-backend-vmware.xml b/doc/config-reference/image-service/section_image-service-backend-vmware.xml index 06b4ff06ff..0cd5358d28 100644 --- a/doc/config-reference/image-service/section_image-service-backend-vmware.xml +++ b/doc/config-reference/image-service/section_image-service-backend-vmware.xml @@ -4,10 +4,10 @@ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="vmware-glance-backend"> - Configure vCenter data stores for the Image Service back + <title>Configure vCenter data stores for the Image service back end - To use vCenter data stores for the Image Service back end, + To use vCenter data stores for the Image service back end, you must update the glance-api.conf file, as follows: @@ -20,7 +20,7 @@ - You must configure any configured Image Service data + You must configure any configured Image service data stores for the Compute service. You can specify vCenter data stores directly by using the diff --git a/doc/config-reference/image-service/section_image-service-backends.xml b/doc/config-reference/image-service/section_image-service-backends.xml index 7f4c905b47..9a3257f40d 100644 --- a/doc/config-reference/image-service/section_image-service-backends.xml +++ b/doc/config-reference/image-service/section_image-service-backends.xml @@ -5,7 +5,7 @@ version="5.0" xml:id="configuring-image-service-backends"> Configure back ends - The Image Service supports several back ends for storing + The Image service supports several back ends for storing virtual machine images: OpenStack Block Storage (cinder) diff --git a/doc/config-reference/image-service/section_image-service-rpc.xml b/doc/config-reference/image-service/section_image-service-rpc.xml index 39bd14cd7b..06c3f4da34 100644 --- a/doc/config-reference/image-service/section_image-service-rpc.xml +++ b/doc/config-reference/image-service/section_image-service-rpc.xml @@ -12,7 +12,7 @@ Qpid, and ZeroMQ. The following tables contain settings to configure the - messaging middleware for the Image Service: + messaging middleware for the Image service: diff --git a/doc/config-reference/image-service/section_image-service-sample-configuration-files.xml b/doc/config-reference/image-service/section_image-service-sample-configuration-files.xml index b53249e8ef..42d86121df 100644 --- a/doc/config-reference/image-service/section_image-service-sample-configuration-files.xml +++ b/doc/config-reference/image-service/section_image-service-sample-configuration-files.xml @@ -3,20 +3,20 @@ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="section_image-service-sample-configuration-files"> - Image Service sample configuration files + Image service sample configuration files You can find the files that are described in this section in the /etc/glance/ directory.
glance-api.conf - The configuration file for the Image Service API is found in the + The configuration file for the Image service API is found in the glance-api.conf file. This file must be modified after installation.
glance-registry.conf - Configuration for the Image Service's registry, which + Configuration for the Image service's registry, which stores the metadata about images, is found in the glance-registry.conf file. This file must be modified after installation. @@ -24,14 +24,14 @@
glance-api-paste.ini - Configuration for the Image Service's API middleware pipeline is found in the + Configuration for the Image service's API middleware pipeline is found in the glance-api-paste.ini file. You should not need to modify this file.
glance-manage.conf - The Image Service's custom logging options are found in the + The Image service's custom logging options are found in the glance-manage.conf file. Options set in glance-manage.conf will override options of the same section and name set in @@ -42,13 +42,13 @@
glance-registry-paste.ini - The Image Service's middleware pipeline for its registry is found in the + The Image service's middleware pipeline for its registry is found in the glance-registry-paste.ini file.
glance-scrubber.conf - glance-scrubber is a utility for the Image Service that cleans + glance-scrubber is a utility for the Image service that cleans up images that have been deleted; its configuration is stored in the glance-scrubber.conf file. Multiple instances of glance-scrubber can be run in a single @@ -63,7 +63,7 @@
policy.json The /etc/glance/policy.json file defines additional access controls - that apply to the Image Service. + that apply to the Image service.
diff --git a/doc/config-reference/table_default-ports-primary-services.xml b/doc/config-reference/table_default-ports-primary-services.xml index 703c52bbb9..d87e9de7c7 100644 --- a/doc/config-reference/table_default-ports-primary-services.xml +++ b/doc/config-reference/table_default-ports-primary-services.xml @@ -71,12 +71,12 @@ publicurl - Image Service (glance) API + Image service (glance) API 9292 publicurl and adminurl - Image Service registry + Image service registry 9191 diff --git a/doc/glossary/glossary-terms.xml b/doc/glossary/glossary-terms.xml index 031d281e4a..db4c16285c 100644 --- a/doc/glossary/glossary-terms.xml +++ b/doc/glossary/glossary-terms.xml @@ -911,7 +911,7 @@ The persistent data store used to save and retrieve information for a service, such as lists of Object Storage objects, current state of guest VMs, lists of user names, and so on. Also, the method that the - Image Service uses to get and store VM images. Options include Object + Image service uses to get and store VM images. Options include Object Storage, local file system, S3, and HTTP. @@ -950,7 +950,7 @@ - An Image Service container format that indicates that no + An Image service container format that indicates that no container exists for the VM image. @@ -1256,7 +1256,7 @@ - A program that keeps the Image Service VM image cache at or + A program that keeps the Image service VM image cache at or below its configured maximum size. @@ -1270,7 +1270,7 @@ An OpenStack grouped release of projects that came out in the spring of 2011. It included Compute (nova), Object Storage (swift), - and the Image Service (glance). + and the Image service (glance). Cactus is a city in Texas, US and is the code name for the third release of OpenStack. When OpenStack releases went from three to six months long, the code name of the release @@ -1788,7 +1788,7 @@ Reducing the size of files by special encoding, the file can be decompressed again to its original content. OpenStack supports compression at the Linux file system level but does not support - compression for things such as Object Storage objects or Image Service + compression for things such as Object Storage objects or Image service VM images. @@ -1959,7 +1959,7 @@ Organizes and stores objects in Object Storage. Similar to the concept of a Linux directory but cannot be nested. Alternative term - for an Image Service container format. + for an Image service container format. @@ -2002,7 +2002,7 @@ - A wrapper used by the Image Service that contains a VM image and + A wrapper used by the Image service that contains a VM image and its associated metadata, such as machine state, OS disk size, and so on. @@ -2073,7 +2073,7 @@ Depending on context, the core API is either the OpenStack API or the main API of a specific core project, such as Compute, - Networking, Image Service, and so on. + Networking, Image service, and so on. @@ -2085,7 +2085,7 @@ An official OpenStack project. Currently consists of Compute - (nova), Object Storage (swift), Image Service (glance), Identity + (nova), Object Storage (swift), Image service (glance), Identity (keystone), Dashboard (horizon), Networking (neutron), and Block Storage (cinder). The Telemetry module (ceilometer) and Orchestration module (heat) are integrated projects as of the Havana release. In the @@ -2240,7 +2240,7 @@ - Both Image Service and Compute support encrypted virtual machine + Both Image service and Compute support encrypted virtual machine (VM) images (but not instances). In-transit data encryption is supported in OpenStack using technologies such as HTTPS, SSL, TLS, and SSH. Object Storage does not support object encryption at the @@ -2388,7 +2388,7 @@ - An option within Image Service so that an image is deleted after + An option within Image service so that an image is deleted after a predefined number of seconds instead of immediately. @@ -2630,7 +2630,7 @@ The underlying format that a disk image for a VM is stored as - within the Image Service back-end store. For example, AMI, ISO, QCOW2, + within the Image service back-end store. For example, AMI, ISO, QCOW2, VMDK, and so on. @@ -3165,7 +3165,7 @@ - VM image container format supported by Image Service. + VM image container format supported by Image service. @@ -3504,7 +3504,7 @@ - UUID for each Compute or Image Service VM flavor or instance + UUID for each Compute or Image service VM flavor or instance type. @@ -3539,7 +3539,7 @@ A grouped release of projects related to OpenStack that came out in the fall of 2012, the sixth release of OpenStack. It includes Compute (nova), Object Storage (swift), Identity (keystone), - Networking (neutron), Image Service (glance), and Volumes or Block + Networking (neutron), Image service (glance), and Volumes or Block Storage (cinder). Folsom is the code name for the sixth release of OpenStack. The design summit took place in @@ -3618,7 +3618,7 @@ glance - A core project that provides the OpenStack Image Service. + A core project that provides the OpenStack Image service. @@ -3631,7 +3631,7 @@ - Processes client requests for VMs, updates Image Service + Processes client requests for VMs, updates Image service metadata on the registry server, and communicates with the store adapter to upload VM images from the back-end store. @@ -3646,7 +3646,7 @@ - Alternative term for the Image Service image registry. + Alternative term for the Image service image registry. @@ -4209,13 +4209,13 @@ Image API - Image Service + Image service - Image Service API + Image service API - The Image Service API endpoint for management of VM + The Image service API endpoint for management of VM images. @@ -4223,13 +4223,13 @@ image cache - Image Service + Image service image cache - Used by Image Service to obtain images on the local host rather + Used by Image service to obtain images on the local host rather than re-downloading them from the image server each time one is requested. @@ -4244,7 +4244,7 @@ - Combination of a URI and UUID used to access Image Service VM + Combination of a URI and UUID used to access Image service VM images through the image API. @@ -4252,7 +4252,7 @@ image membership - Image Service + Image service image membership @@ -4266,13 +4266,13 @@ image owner - Image Service + Image service image owner - The tenant who owns an Image Service virtual machine + The tenant who owns an Image service virtual machine image. @@ -4280,7 +4280,7 @@ image registry - Image Service + Image service image registry @@ -4292,17 +4292,17 @@ - Image Service + Image service An OpenStack core project that provides discovery, registration, and delivery services for disk and server images. The project name of - the Image Service is glance. + the Image service is glance. - Image Service API + Image service API Alternative name for the glance image API. @@ -4312,13 +4312,13 @@ image status - Image Service + Image service image status - The current status of a VM image in Image Service, not to be + The current status of a VM image in Image service, not to be confused with the status of a running instance. @@ -4326,13 +4326,13 @@ image store - Image Service + Image service image store - The back-end store used by Image Service to store VM images, + The back-end store used by Image service to store VM images, options include Object Storage, local file system, S3, or HTTP. @@ -4340,13 +4340,13 @@ image UUID - Image Service + Image service image UUID - UUID used by Image Service to uniquely identify each VM + UUID used by Image service to uniquely identify each VM image. @@ -4698,7 +4698,7 @@ The SCSI disk protocol tunneled within Ethernet, supported by - Compute, Object Storage, and Image Service. + Compute, Object Storage, and Image service. @@ -5237,7 +5237,7 @@ - The association between an Image Service VM image and a tenant. + The association between an Image service VM image and a tenant. Enables images to be shared with specified tenants. @@ -6496,7 +6496,7 @@ - An Image Service VM image that is only available to specified + An Image service VM image that is only available to specified tenants. @@ -6602,7 +6602,7 @@ - Generally, extra properties on an Image Service image to + Generally, extra properties on an Image service image to which only cloud administrators have access. Limits which user roles can perform CRUD operations on that property. The cloud administrator can configure any image property as @@ -6676,7 +6676,7 @@ public image - Image Service + Image service public images @@ -6685,7 +6685,7 @@ - An Image Service VM image that is available to all + An Image service VM image that is available to all tenants. @@ -6930,7 +6930,7 @@ - One of the VM image disk formats supported by Image Service; an + One of the VM image disk formats supported by Image service; an unstructured disk image. @@ -7062,11 +7062,11 @@ registry - under Image Service + under Image service - Alternative term for the Image Service registry. + Alternative term for the Image service registry. @@ -7082,7 +7082,7 @@ - An Image Service that provides VM image metadata information to + An Image service that provides VM image metadata information to clients. @@ -7406,7 +7406,7 @@ Object storage service by Amazon; similar in function to Object - Storage, it can act as a back-end store for Image Service VM images. @@ -8047,7 +8047,7 @@ - Specifies the authentication source used by Image Service or + Specifies the authentication source used by Image service or Identity Service. diff --git a/doc/image-guide/ch_modifying_images.xml b/doc/image-guide/ch_modifying_images.xml index ce25a2f81a..dc5506b50b 100644 --- a/doc/image-guide/ch_modifying_images.xml +++ b/doc/image-guide/ch_modifying_images.xml @@ -12,7 +12,7 @@ Once you have obtained a virtual machine image, you may want to make some changes to it before uploading it to the - OpenStack Image Service. Here we describe several tools + OpenStack Image service. Here we describe several tools available that allow you to modify images. Do not attempt to use these tools to modify an image that is attached to a running virtual machine. These diff --git a/doc/image-guide/section_centos-example.xml b/doc/image-guide/section_centos-example.xml index b1db92c020..75d874616b 100644 --- a/doc/image-guide/section_centos-example.xml +++ b/doc/image-guide/section_centos-example.xml @@ -317,7 +317,7 @@ kernel ... console=tty0 console=ttyS0,115200n8 Undefine the libvirt domain - Now that you can upload the image to the Image Service, you no longer need to have + Now that you can upload the image to the Image service, you no longer need to have this virtual machine image managed by libvirt. Use the virsh undefine vm-image command to inform libvirt: # virsh undefine centos-6.4 @@ -326,6 +326,6 @@ kernel ... console=tty0 console=ttyS0,115200n8Image is complete The underlying image file that you created with qemu-img create is ready to be uploaded. For example, you can upload the - /tmp/centos-6.4.qcow2 image to the Image Service. + /tmp/centos-6.4.qcow2 image to the Image service.
diff --git a/doc/image-guide/section_fedora-example.xml b/doc/image-guide/section_fedora-example.xml index 982cab4598..fc69c15f32 100644 --- a/doc/image-guide/section_fedora-example.xml +++ b/doc/image-guide/section_fedora-example.xml @@ -165,5 +165,5 @@ kernel ... console=tty0 console=ttyS0,115200n8 # virsh undefine fedora-20 The underlying image file that you created with qemu-img create is - ready to be uploaded to the Image Service. + ready to be uploaded to the Image service.
diff --git a/doc/image-guide/section_glance-image-metadata.xml b/doc/image-guide/section_glance-image-metadata.xml index a804ba8de3..fed7e5ada7 100644 --- a/doc/image-guide/section_glance-image-metadata.xml +++ b/doc/image-guide/section_glance-image-metadata.xml @@ -7,7 +7,7 @@ Image metadata Image metadata can help end users determine the nature of an image, and is used by - associated OpenStack components and drivers which interface with the Image Service. + associated OpenStack components and drivers which interface with the Image service. Metadata can also determine the scheduling of hosts. If the option is set on an image, and Compute is configured so that the ImagePropertiesFilter scheduler filter is enabled (default), then the @@ -15,7 +15,7 @@ Compute's ImagePropertiesFilter value is specified in the value in the /etc/nova/nova.conf file. - You can add metadata to Image Service images by using the --property + You can add metadata to Image service images by using the --property key=value option with the glance image-create or glance image-update command. More than one property can be specified. For example: diff --git a/doc/image-guide/section_glance_image-formats.xml b/doc/image-guide/section_glance_image-formats.xml index 2a32517265..d5f5bfd333 100644 --- a/doc/image-guide/section_glance_image-formats.xml +++ b/doc/image-guide/section_glance_image-formats.xml @@ -6,7 +6,7 @@ xml:id="image-formats"> Disk and container formats for images - When you add an image to the Image Service, you can specify + When you add an image to the Image service, you can specify its disk and container formats.
Disk formats @@ -68,7 +68,7 @@ machine image is in a file format that also contains metadata about the actual virtual machine. - The Image Service and other OpenStack projects do + The Image service and other OpenStack projects do not currently support the container format. It is safe to specify bare as the container format if you are unsure. diff --git a/doc/image-guide/section_ubuntu-example.xml b/doc/image-guide/section_ubuntu-example.xml index ddae6efb20..c36a7c4225 100644 --- a/doc/image-guide/section_ubuntu-example.xml +++ b/doc/image-guide/section_ubuntu-example.xml @@ -192,7 +192,7 @@ Undefine the libvirt domain - Now that the image is ready to be uploaded to the Image Service, you no longer need to + Now that the image is ready to be uploaded to the Image service, you no longer need to have this virtual machine image managed by libvirt. Use the virsh undefine vm-image command to inform libvirt: # virsh undefine trusty @@ -201,6 +201,6 @@ Image is complete The underlying image file that you created with qemu-img create, such as /tmp/trusty.qcow2, is now ready for uploading to the - OpenStack Image Service. + OpenStack Image service.
diff --git a/doc/image-guide/section_windows-example.xml b/doc/image-guide/section_windows-example.xml index 10922e9951..e70d835224 100644 --- a/doc/image-guide/section_windows-example.xml +++ b/doc/image-guide/section_windows-example.xml @@ -98,7 +98,7 @@ - Your image is ready to upload to the Image Service: + Your image is ready to upload to the Image service: $ glance image-create --name WS2012 --disk-format qcow2 \ --container-format bare --is-public true \ --file ws2012.qcow2 diff --git a/doc/install-guide/ch_basic_environment.xml b/doc/install-guide/ch_basic_environment.xml index 0e3f9048bb..9fb097d734 100644 --- a/doc/install-guide/ch_basic_environment.xml +++ b/doc/install-guide/ch_basic_environment.xml @@ -24,13 +24,13 @@ three-node architecture with OpenStack Networking (neutron). - Although most environments include Identity, Image Service, + Although most environments include Identity, Image service, Compute, at least one networking service, and the dashboard, the Object Storage service can operate independently. If your use case only involves Object Storage, you can skip to after configuring the appropriate nodes for it. However, the dashboard requires at least - the Image Service and Compute. + the Image service and Compute. You must use an account with administrative privileges to configure diff --git a/doc/install-guide/ch_glance.xml b/doc/install-guide/ch_glance.xml index 2ccb3d6c7f..0a9afb28f2 100644 --- a/doc/install-guide/ch_glance.xml +++ b/doc/install-guide/ch_glance.xml @@ -4,18 +4,18 @@ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="ch_glance"> - Add the Image Service - The OpenStack Image Service (glance) enables users to discover, + Add the Image service + The OpenStack Image service (glance) enables users to discover, register, and retrieve virtual machine images. It offers a REST API that enables you to query virtual machine image metadata and retrieve an actual image. You can store virtual machine images made available through the - Image Service in a variety of locations, from simple file systems + Image service in a variety of locations, from simple file systems to object-storage systems like OpenStack Object Storage. - For simplicity, this guide describes configuring the Image Service to + For simplicity, this guide describes configuring the Image service to use the file back end, which uploads and stores in a - directory on the controller node hosting the Image Service. By + directory on the controller node hosting the Image service. By default, this directory is /var/lib/glance/images/. Before you proceed, ensure that the controller node has at least diff --git a/doc/install-guide/ch_overview.xml b/doc/install-guide/ch_overview.xml index dca0450643..5268e1601b 100644 --- a/doc/install-guide/ch_overview.xml +++ b/doc/install-guide/ch_overview.xml @@ -168,7 +168,7 @@ The controller node runs the Identity service, - Image Service, management portion of Compute, and the + Image service, management portion of Compute, and the dashboard. It also includes supporting services such as a SQL database, message queue, and Network Time Protocol (NTP). diff --git a/doc/install-guide/section_basics-security.xml b/doc/install-guide/section_basics-security.xml index 18f38179f6..314ebd704e 100644 --- a/doc/install-guide/section_basics-security.xml +++ b/doc/install-guide/section_basics-security.xml @@ -66,11 +66,11 @@ GLANCE_DBPASS - Database password for Image Service + Database password for Image service GLANCE_PASS - Password of Image Service user glance + Password of Image service user glance HEAT_DBPASS diff --git a/doc/install-guide/section_ceilometer-glance.xml b/doc/install-guide/section_ceilometer-glance.xml index b1960a1941..e510c9585d 100644 --- a/doc/install-guide/section_ceilometer-glance.xml +++ b/doc/install-guide/section_ceilometer-glance.xml @@ -4,9 +4,9 @@ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="ceilometer-glance"> - Configure the Image Service + Configure the Image service To retrieve image-oriented events and samples, configure - the Image Service to send notifications to the message bus. + the Image service to send notifications to the message bus. Perform these steps on the controller node. Edit the /etc/glance/glance-api.conf @@ -26,7 +26,7 @@ rabbit_password = RABBIT_PASS RabbitMQ. - Restart the Image Service: + Restart the Image service: # service glance-registry restart # service glance-api restart # systemctl restart openstack-glance-api.service openstack-glance-registry.service diff --git a/doc/install-guide/section_ceilometer-verify.xml b/doc/install-guide/section_ceilometer-verify.xml index fb8a49f34c..a915e2b1ae 100644 --- a/doc/install-guide/section_ceilometer-verify.xml +++ b/doc/install-guide/section_ceilometer-verify.xml @@ -31,7 +31,7 @@ - Download an image from the Image Service: + Download an image from the Image service: $ glance image-download "cirros-0.3.3-x86_64" > cirros.img diff --git a/doc/install-guide/section_cinder-storage-node.xml b/doc/install-guide/section_cinder-storage-node.xml index 19ba35d2d9..c6095640b8 100644 --- a/doc/install-guide/section_cinder-storage-node.xml +++ b/doc/install-guide/section_cinder-storage-node.xml @@ -200,7 +200,7 @@ my_ip = MANAGEMENT_INTERFACE_IP_ADDRESS In the [DEFAULT] section, configure the - location of the Image Service: + location of the Image service: [DEFAULT] ... glance_host = controller diff --git a/doc/install-guide/section_dashboard-install.xml b/doc/install-guide/section_dashboard-install.xml index bf653b8603..31ea556414 100644 --- a/doc/install-guide/section_dashboard-install.xml +++ b/doc/install-guide/section_dashboard-install.xml @@ -10,7 +10,7 @@ on the controller node. Before you proceed, verify that your system meets the requirements in . Also, the dashboard - relies on functional core services including Identity, Image Service, + relies on functional core services including Identity, Image service, Compute, and either Networking (neutron) or legacy networking (nova-network). Environments with stand-alone services such as Object Storage cannot use the dashboard. For more information, see the diff --git a/doc/install-guide/section_debconf-concepts.xml b/doc/install-guide/section_debconf-concepts.xml index 20562f2fca..2cb04b927e 100644 --- a/doc/install-guide/section_debconf-concepts.xml +++ b/doc/install-guide/section_debconf-concepts.xml @@ -61,7 +61,7 @@ files. For example, the glance-common package installs the glance-api.conf and glance-registry.conf files. So, for the - Image Service, you must re-configure the + Image service, you must re-configure the glance-common package. The same applies for cinder-common, nova-common, and diff --git a/doc/install-guide/section_debconf-keystone_authtoken.xml b/doc/install-guide/section_debconf-keystone_authtoken.xml index 68d07ca4d1..2a43033036 100644 --- a/doc/install-guide/section_debconf-keystone_authtoken.xml +++ b/doc/install-guide/section_debconf-keystone_authtoken.xml @@ -22,7 +22,7 @@ admin_password = %SERVICE_PASSWORD% auth_uri, identity_uri, admin_tenant_name, admin_user and admin_password options. - The following screens show an example Image Service + The following screens show an example Image service configuration: diff --git a/doc/install-guide/section_glance-install.xml b/doc/install-guide/section_glance-install.xml index 9d1e490a6e..6d66f049cf 100644 --- a/doc/install-guide/section_glance-install.xml +++ b/doc/install-guide/section_glance-install.xml @@ -5,7 +5,7 @@ version="5.0" xml:id="glance-install"> Install and configure - This section describes how to install and configure the Image Service, + This section describes how to install and configure the Image service, code-named glance, on the controller node. For simplicity, this configuration stores images on the local file system. @@ -16,7 +16,7 @@ To configure prerequisites - Before you install and configure the Image Service, you must + Before you install and configure the Image service, you must create a database, service credentials, and API endpoints. To create the database, complete these steps: @@ -83,11 +83,11 @@ Repeat User Password: Create the glance service entity: $ openstack service create --type image \ - --description "OpenStack Image Service" glance + --description "OpenStack Image service" glance +-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ -| description | OpenStack Image Service | +| description | OpenStack Image service | | enabled | True | | id | 178124d6081c441b80d79972614149c6 | | name | glance | @@ -97,7 +97,7 @@ Repeat User Password: - Create the Image Service API endpoints: + Create the Image service API endpoints: $ openstack endpoint create \ --publicurl http://controller:9292 \ --internalurl http://controller:9292 \ @@ -119,7 +119,7 @@ Repeat User Password: - To install and configure the Image Service components + To install and configure the Image service components Default configuration files vary by distribution. You might need to add these sections and options rather than modifying existing @@ -144,7 +144,7 @@ Repeat User Password: ... connection = mysql://glance:GLANCE_DBPASS@controller/glance Replace GLANCE_DBPASS with the - password you chose for the Image Service database. + password you chose for the Image service database. In the [keystone_authtoken] and @@ -188,7 +188,7 @@ filesystem_store_datadir = /var/lib/glance/images/ [DEFAULT] ... notification_driver = noop - The Telemetry chapter provides an Image Service configuration + The Telemetry chapter provides an Image service configuration that enables notifications. @@ -212,7 +212,7 @@ verbose = True ... connection = mysql://glance:GLANCE_DBPASS@controller/glance Replace GLANCE_DBPASS with the - password you chose for the Image Service database. + password you chose for the Image service database. In the [keystone_authtoken] and @@ -248,7 +248,7 @@ flavor = keystone [DEFAULT] ... notification_driver = noop - The Telemetry chapter provides an Image Service configuration + The Telemetry chapter provides an Image service configuration that enables notifications. @@ -262,12 +262,12 @@ verbose = True - Populate the Image Service database: + Populate the Image service database: # su -s /bin/sh -c "glance-manage db_sync" glance - To install and configure the Image Service components + To install and configure the Image service components Install the packages: # apt-get install glance python-glanceclient @@ -284,7 +284,7 @@ verbose = True Select the keystone pipeline to configure the - Image Service to use the Identity service: + Image service to use the Identity service: To finalize installation - Restart the Image Service services: + Restart the Image service services: # service glance-registry restart # service glance-api restart - Start the Image Service services and configure them to start when + Start the Image service services and configure them to start when the system boots: # systemctl enable openstack-glance-api.service openstack-glance-registry.service # systemctl start openstack-glance-api.service openstack-glance-registry.service diff --git a/doc/install-guide/section_glance-verify.xml b/doc/install-guide/section_glance-verify.xml index e16290f673..80bbab106d 100644 --- a/doc/install-guide/section_glance-verify.xml +++ b/doc/install-guide/section_glance-verify.xml @@ -5,7 +5,7 @@ version="5.0" xml:id="glance-verify"> Verify operation - Verify operation of the Image Service using + Verify operation of the Image service using CirrOS, a small Linux image that helps you test your OpenStack deployment. For more information about how to download and build images, @@ -31,7 +31,7 @@ $ wget -P /tmp/images http://cdn.download.cirros-cloud.net/0.3.3/cirros-0.3.3-x86_64-disk.img - Upload the image to the Image Service using the + Upload the image to the Image service using the QCOW2 disk format, bare container format, and public visibility so all projects can access it: @@ -61,7 +61,7 @@ For information about the glance image-create parameters, see Image Service command-line client in the + >Image service command-line client in the OpenStack Command-Line Interface Reference. For information about disk and container formats for diff --git a/doc/install-guide/section_nova-compute-install.xml b/doc/install-guide/section_nova-compute-install.xml index a5cb9e794e..3c797bef8a 100644 --- a/doc/install-guide/section_nova-compute-install.xml +++ b/doc/install-guide/section_nova-compute-install.xml @@ -141,7 +141,7 @@ novncproxy_base_url = http://controller:6080/vnc_auto In the [glance] section, configure the - location of the Image Service: + location of the Image service: [glance] ... host = controller diff --git a/doc/install-guide/section_nova-controller-install.xml b/doc/install-guide/section_nova-controller-install.xml index 17f9f018ce..25d842014e 100644 --- a/doc/install-guide/section_nova-controller-install.xml +++ b/doc/install-guide/section_nova-controller-install.xml @@ -207,7 +207,7 @@ vncserver_proxyclient_address = 10.0.0.11 In the [glance] section, configure the - location of the Image Service: + location of the Image service: [glance] ... host = controller diff --git a/doc/install-guide/section_nova-verify.xml b/doc/install-guide/section_nova-verify.xml index be09d3b16e..ecf407949e 100644 --- a/doc/install-guide/section_nova-verify.xml +++ b/doc/install-guide/section_nova-verify.xml @@ -123,8 +123,8 @@ +-----------+----------------------------------+ - List images in the Image Service catalog to verify connectivity - with the Image Service: + List images in the Image service catalog to verify connectivity + with the Image service: $ nova image-list +--------------------------------------+---------------------+--------+--------+ | ID | Name | Status | Server | diff --git a/doc/install-guide/section_trove-install.xml b/doc/install-guide/section_trove-install.xml index 404d84a46b..d715302b97 100644 --- a/doc/install-guide/section_trove-install.xml +++ b/doc/install-guide/section_trove-install.xml @@ -11,7 +11,7 @@ Prerequisites This chapter assumes that you already have a working OpenStack environment with at least the following components - installed: Compute, Image Service, Identity. + installed: Compute, Image service, Identity. diff --git a/doc/user-guide/app_cheat_sheet.xml b/doc/user-guide/app_cheat_sheet.xml index 8fcc061143..ad3431df49 100644 --- a/doc/user-guide/app_cheat_sheet.xml +++ b/doc/user-guide/app_cheat_sheet.xml @@ -59,7 +59,7 @@ - + diff --git a/doc/user-guide/section_cli_nova_boot.xml b/doc/user-guide/section_cli_nova_boot.xml index d0a23c2329..cd41e2b366 100644 --- a/doc/user-guide/section_cli_nova_boot.xml +++ b/doc/user-guide/section_cli_nova_boot.xml @@ -95,7 +95,7 @@ linkend="boot_from_volume">volume. You can launch an instance directly from one of the available OpenStack images or from an image that you have copied to a persistent - volume. The OpenStack Image Service provides a pool of images + volume. The OpenStack Image service provides a pool of images that are accessible to members of different projects.
diff --git a/doc/user-guide/section_dashboard_launch_instances.xml b/doc/user-guide/section_dashboard_launch_instances.xml index f1f9c025ce..af6ca3f669 100644 --- a/doc/user-guide/section_dashboard_launch_instances.xml +++ b/doc/user-guide/section_dashboard_launch_instances.xml @@ -10,7 +10,7 @@ You can launch an instance from the following sources: - Images uploaded to the OpenStack Image Service, as described + Images uploaded to the OpenStack Image service, as described in . Image that you have copied to a persistent volume. The instance launches from the volume, which is provided by the diff --git a/doc/user-guide/section_dashboard_launch_instances_from_image.xml b/doc/user-guide/section_dashboard_launch_instances_from_image.xml index 4e2b25f7c8..9ab4d2cb53 100644 --- a/doc/user-guide/section_dashboard_launch_instances_from_image.xml +++ b/doc/user-guide/section_dashboard_launch_instances_from_image.xml @@ -35,7 +35,7 @@ Log in to the dashboard, choose a project, and click Images. The dashboard shows the images that have been uploaded to - OpenStack Image Service and are available for this + OpenStack Image service and are available for this project. For details on creating images, see - Authenticate against an Image Service endpoint - To authenticate against an Image Service endpoint, instantiate + Authenticate against an Image service endpoint + To authenticate against an Image service endpoint, instantiate a glanceclient.v2.client.Client object: diff --git a/doc/user-guide/section_sdk_manage_images.xml b/doc/user-guide/section_sdk_manage_images.xml index 24d8849e0c..d248dcf859 100644 --- a/doc/user-guide/section_sdk_manage_images.xml +++ b/doc/user-guide/section_sdk_manage_images.xml @@ -87,7 +87,7 @@ image = glance.images.get(image_id)
Get image by name - The Image Service Python bindings do not support the + The Image service Python bindings do not support the retrieval of an image object by name. However, the Compute Python bindings enable you to get an image object by name. To get an image object by name, call the
Image Service (glance)Image service (glance)