From 5f0ea63b60dbec6175145f975789253d2a956384 Mon Sep 17 00:00:00 2001 From: gaofei Date: Tue, 23 Jan 2018 16:24:06 +0800 Subject: [PATCH] Replace Chinese punctuation with English punctuation Change-Id: I991282cd7547dddf2324cdf1ea63bd12d4303ab1 --- .../contributor/attach_detach_conventions.rst | 2 +- doc/source/contributor/auth.rst | 4 ++-- doc/source/contributor/migration.rst | 22 +++++++++---------- ...tacore-volume-driver-3775797b0515f538.yaml | 2 +- ...o-enable-multiattach-e7d84ffa282842e9.yaml | 2 +- 5 files changed, 16 insertions(+), 16 deletions(-) diff --git a/doc/source/contributor/attach_detach_conventions.rst b/doc/source/contributor/attach_detach_conventions.rst index 79384e519a1..b01bf22b4e2 100644 --- a/doc/source/contributor/attach_detach_conventions.rst +++ b/doc/source/contributor/attach_detach_conventions.rst @@ -56,7 +56,7 @@ NOTE: multi-attach will add "in-use" to the above acceptable states. If the volume is in fact available, we immediately issue an update to the Cinder database and mark the status of the volume to “attaching” thereby reserving the -volume so that it won’t be used by another API call anywhere else. +volume so that it won't be used by another API call anywhere else. initialize_connection(self, context, volume, connector) ------------------------------------------------------- diff --git a/doc/source/contributor/auth.rst b/doc/source/contributor/auth.rst index 166a8bfd022..58af2db7523 100644 --- a/doc/source/contributor/auth.rst +++ b/doc/source/contributor/auth.rst @@ -185,7 +185,7 @@ Existing API calls to launch instances specific a single, combined “type” fl RunInstances type=m1.large number=1 secgroup=default key=mykey confidentiality=low integrity=low availability=low -These additional parameters would also apply to creation of block storage volumes (along with the existing parameter of ‘size’), and creation of object storage ‘buckets’. (C.I.A. classifications on a bucket would be inherited by the keys within this bucket.) +These additional parameters would also apply to creation of block storage volumes (along with the existing parameter of 'size'), and creation of object storage 'buckets'. (C.I.A. classifications on a bucket would be inherited by the keys within this bucket.) Request Brokering @@ -206,7 +206,7 @@ Dirty Cloud - Hybrid Data Centers * CloudAudit bridge interfaces * Anything in the ARP table -A hybrid cloud environment provides dedicated, potentially co-located physical hardware with a network interconnect to the project or users’ cloud virtual network. +A hybrid cloud environment provides dedicated, potentially co-located physical hardware with a network interconnect to the project or user's cloud virtual network. This interconnect is typically a bridged VPN connection. Any machines that can be bridged into a hybrid environment in this fashion (at Layer 2) must implement a minimum version of the CloudAudit spec, such that they can be queried to provide a complete picture of the IT-sec runtime environment. diff --git a/doc/source/contributor/migration.rst b/doc/source/contributor/migration.rst index b295c5c1191..0027e7896ad 100644 --- a/doc/source/contributor/migration.rst +++ b/doc/source/contributor/migration.rst @@ -26,7 +26,7 @@ the destination volume is located, and both of them share the same Cinder API service, scheduler service, message queue service, etc. As a general rule migration is possible for volumes in 'available' or -‘in-use’ status, for the driver which has implemented volume migration. +'in-use' status, for the driver which has implemented volume migration. So far, we are confident that migration will succeed for 'available' volumes, whose drivers implement the migration routines. However, the migration of 'in-use' volumes is driver dependent. It depends on @@ -109,7 +109,7 @@ To set up an environment to try the volume migration, we need to configure at least two different back-ends on the same node of cinder volume service, c-vol node or two back-ends on two different volume nodes of cinder volume service, c-vol nodes. Which command to use, -‘cinder migrate’ or ‘cinder retype’, depends on which type of volume +'cinder migrate' or 'cinder retype', depends on which type of volume we would like to test. **Scenario 1 for migration** @@ -191,19 +191,19 @@ What can be tracked during volume migration The volume migration is an administrator only action and it may take a relatively long time to finish. The property ‘migration status’ will indicate the stage of the migration process for the volume. The -administrator can check the ‘migration status’ via the ‘cinder list’ -or ‘cinder show ’ command. The ‘cinder list’ command presents +administrator can check the 'migration status' via the 'cinder list' +or 'cinder show ' command. The 'cinder list' command presents a list of all the volumes with some properties displayed, including the migration status, only to the administrator. However, the migration status -is not included if ‘cinder list’ is issued by an ordinary user. The -‘cinder show ’ will present all the detailed information of a +is not included if 'cinder list' is issued by an ordinary user. The +'cinder show ' will present all the detailed information of a specific volume, including the migration status, only to the administrator. -If the migration status of a volume shows ‘starting’, ‘migrating’ or -‘completing’, it means the volume is in the process of a migration. -If the migration status is ‘success’, it means the migration has finished +If the migration status of a volume shows 'starting', 'migrating' or +'completing', it means the volume is in the process of a migration. +If the migration status is 'success', it means the migration has finished and the previous migration of this volume succeeded. If the -migration status is ‘error’, it means the migration has finished and +migration status is 'error', it means the migration has finished and the previous migration of this volume failed. @@ -218,7 +218,7 @@ is based on the volume attachment to the node of cinder volume service, c-vol node. Any back-end driver supporting iSCSI will be able to support the generic host-assisted migration for sure. The back-end driver without iSCSI supported needs to be tested to decide if it supports this kind of -migration. The block-based transfer mode is done by ‘dd’ command, +migration. The block-based transfer mode is done by 'dd' command, applying to drivers like LVM, Storwize, etc, and the file-based transfer mode is done by file copy, typically applying to the RBD driver. diff --git a/releasenotes/notes/add-datacore-volume-driver-3775797b0515f538.yaml b/releasenotes/notes/add-datacore-volume-driver-3775797b0515f538.yaml index 810d04fdcff..c7213ddb32a 100644 --- a/releasenotes/notes/add-datacore-volume-driver-3775797b0515f538.yaml +++ b/releasenotes/notes/add-datacore-volume-driver-3775797b0515f538.yaml @@ -1,4 +1,4 @@ --- features: - - Added iSCSI and Fibre Channel volume drivers for DataCore’s + - Added iSCSI and Fibre Channel volume drivers for DataCore's SANsymphony and Hyper-converged Virtual SAN storage. diff --git a/releasenotes/notes/scaleio-enable-multiattach-e7d84ffa282842e9.yaml b/releasenotes/notes/scaleio-enable-multiattach-e7d84ffa282842e9.yaml index e0e1c1cce95..bc104cd424a 100644 --- a/releasenotes/notes/scaleio-enable-multiattach-e7d84ffa282842e9.yaml +++ b/releasenotes/notes/scaleio-enable-multiattach-e7d84ffa282842e9.yaml @@ -2,7 +2,7 @@ features: - | The multiattach capability has been enabled and verified - as working with the ScaleIO driver. It is the users’ + as working with the ScaleIO driver. It is the user's responsibility to add some type of exclusion (at the file system or network file system layer) to prevent multiple writers from corrupting data on the volume.