Replace Chinese punctuation with English punctuation

Change-Id: I8ed8461d0fff743776c5509d2d9f4b51f3b3f36d

doc/feature_request/check_queue_perfdata.rst

@@ -14,7 +14,7 @@ messages count and messages size in queue during tasks.
 Problem description
 -------------------
 
-Heavy usage of queue isn’t checked.
+Heavy usage of queue isn't checked.
 
 Possible solution
 -----------------

doc/release_notes/archive/v0.0.4.rst

@@ -32,7 +32,7 @@ New Features & API changes
   users. To do this, one should set up the "users" section of the deployment
   configuration of the ExistingCloud type. This feature also makes it safer to
   run Rally against production clouds: when run from an isolated group of
-  users, Rally won’t affect rest of the cloud users if something goes wrong.
+  users, Rally won't affect rest of the cloud users if something goes wrong.
 
 * New decorator *@osclients.Clients.register* can add new OpenStack clients
   at runtime

doc/source/quick_start/tutorial/step_3_benchmarking_with_existing_users.rst

@@ -32,7 +32,7 @@ scenarios in Rally is just impossible in case of r/o Keystone backends like
 *LDAP* and *AD*.
 
 2. *Safety:* Rally can be run from an isolated group of users, and if something
-goes wrong, this won’t affect the rest of the cloud users.
+goes wrong, this won't affect the rest of the cloud users.
 
 
 Registering deployment with existing users in Rally

doc/source/quick_start/tutorial/step_5_task_templates.rst

@@ -69,7 +69,7 @@ runs a set of Nova scenarios:
 
 In both scenarios above, the *"^cirros.*-disk$"* image is passed to the
 scenario as an argument (so that these scenarios use an appropriate image while
-booting servers). Let’s say you want to run the same set of scenarios with the
+booting servers). Let's say you want to run the same set of scenarios with the
 same runner/context/sla, but you want to try another image while booting server
 to compare the performance. The most elegant solution is then to turn the image
 name into a template variable:
@@ -294,7 +294,7 @@ increasing concurrency. The input task file (*task.yaml*) below uses the
       {% endfor %}
 
 
-In this case, you don’t need to pass any arguments via
+In this case, you don't need to pass any arguments via
 *--task-args/--task-args-file*, but as soon as you start this task, Rally will
 automatically unfold the for-loop for you:
 

doc/source/quick_start/tutorial/step_6_aborting_load_generation_on_sla_failure.rst

@@ -61,7 +61,7 @@ running more and more simultaneously authentication requests and things may go
 wrong if something is not set properly (like on my DevStack deployment in Small
 VM on my laptop).
 
-Let’s run Rally task with **an argument that prescribes Rally to stop load on
+Let's run Rally task with **an argument that prescribes Rally to stop load on
 SLA failure**:
 
 .. code-block:: console
@@ -80,7 +80,7 @@ On the resulting table there are 2 interesting things:
 1. Average duration was 8.58 sec which is more than 5 seconds
 2. Rally performed only 2495 (instead of 6000) authentication requests
 
-To understand better what has happened let’s generate HTML report:
+To understand better what has happened let's generate HTML report:
 
 .. code-block:: bash
 
@@ -94,7 +94,7 @@ request reaches 65 seconds at the end of the load generation. **Rally stopped
 load at the very last moment just before bad things happened. The reason why it
 runs so many attempts to authenticate is because of not enough good success
 criteria.** We had to run a lot of iterations to make average duration bigger
-than 5 seconds. Let’s chose better success criteria for this task and run it
+than 5 seconds. Let's chose better success criteria for this task and run it
 one more time.
 
 .. code-block:: yaml
@@ -122,7 +122,7 @@ Now our task is going to be successful if the following three conditions hold:
 2. maximum duration of any authentication should be less than 10 seconds
 3. no failed authentication should appear
 
-Let’s run it!
+Let's run it!
 
 .. code-block:: console
 

doc/source/verification/overview.rst

@@ -14,7 +14,7 @@
 Historical background
 ---------------------
 
-Tempest, OpenStack’s official test suite, is a powerful tool for running a set
+Tempest, OpenStack's official test suite, is a powerful tool for running a set
 of functional tests against an OpenStack cluster. Tempest automatically runs
 against every patch in every project of OpenStack, which lets us avoid merging
 changes that break functionality.