From 548d2f5b37998306573be49b3887b7045083d3cd Mon Sep 17 00:00:00 2001 From: gaofei Date: Tue, 23 Jan 2018 17:15:14 +0800 Subject: [PATCH] Replace Chinese punctuation with English punctuation Change-Id: I8ed8461d0fff743776c5509d2d9f4b51f3b3f36d --- doc/feature_request/check_queue_perfdata.rst | 2 +- doc/release_notes/archive/v0.0.4.rst | 2 +- .../tutorial/step_3_benchmarking_with_existing_users.rst | 2 +- doc/source/quick_start/tutorial/step_5_task_templates.rst | 4 ++-- .../step_6_aborting_load_generation_on_sla_failure.rst | 8 ++++---- doc/source/verification/overview.rst | 2 +- 6 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/feature_request/check_queue_perfdata.rst b/doc/feature_request/check_queue_perfdata.rst index cc87eca5..8c004f20 100644 --- a/doc/feature_request/check_queue_perfdata.rst +++ b/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 ----------------- diff --git a/doc/release_notes/archive/v0.0.4.rst b/doc/release_notes/archive/v0.0.4.rst index 77cea72f..8363ebc4 100644 --- a/doc/release_notes/archive/v0.0.4.rst +++ b/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 diff --git a/doc/source/quick_start/tutorial/step_3_benchmarking_with_existing_users.rst b/doc/source/quick_start/tutorial/step_3_benchmarking_with_existing_users.rst index dbde32f6..d3bdb106 100644 --- a/doc/source/quick_start/tutorial/step_3_benchmarking_with_existing_users.rst +++ b/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 diff --git a/doc/source/quick_start/tutorial/step_5_task_templates.rst b/doc/source/quick_start/tutorial/step_5_task_templates.rst index 22eddf86..0e9d5485 100644 --- a/doc/source/quick_start/tutorial/step_5_task_templates.rst +++ b/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: diff --git a/doc/source/quick_start/tutorial/step_6_aborting_load_generation_on_sla_failure.rst b/doc/source/quick_start/tutorial/step_6_aborting_load_generation_on_sla_failure.rst index 9a48ee3b..e526df63 100644 --- a/doc/source/quick_start/tutorial/step_6_aborting_load_generation_on_sla_failure.rst +++ b/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 diff --git a/doc/source/verification/overview.rst b/doc/source/verification/overview.rst index 3c42b71f..a23e5b94 100644 --- a/doc/source/verification/overview.rst +++ b/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.