From 66a7e6138f2e1d5d2217eaee4162248de90cbbee Mon Sep 17 00:00:00 2001 From: chengebj5238 Date: Mon, 5 Feb 2018 18:37:03 +0800 Subject: [PATCH] Repalce Chinese quotes to English quotes Change-Id: Idcd0cdb57019a512f2d3eecdb7bc2b08a34af7e8 --- api-ref/source/v2/l7policy.inc | 2 +- api-ref/source/v2/l7rule.inc | 2 +- doc/source/reference/introduction.rst | 4 ++-- specs/version0.9/active-active-topology.rst | 2 +- specs/version1.1/enable-provider-driver.rst | 8 ++++---- tox.ini | 2 +- 6 files changed, 10 insertions(+), 10 deletions(-) diff --git a/api-ref/source/v2/l7policy.inc b/api-ref/source/v2/l7policy.inc index f4c07e09c3..ba497bc44a 100644 --- a/api-ref/source/v2/l7policy.inc +++ b/api-ref/source/v2/l7policy.inc @@ -96,7 +96,7 @@ response body. Validation errors require that you correct the error and submit the request again. All the rules associated with a given policy are logically ANDed together. A -request must match all the policy’s rules to match the policy. +request must match all the policy's rules to match the policy. If you need to express a logical OR operation between rules, then do this by creating multiple policies with the same action. diff --git a/api-ref/source/v2/l7rule.inc b/api-ref/source/v2/l7rule.inc index 2f424a098c..4ed0f3c19d 100644 --- a/api-ref/source/v2/l7rule.inc +++ b/api-ref/source/v2/l7rule.inc @@ -94,7 +94,7 @@ response body. Validation errors require that you correct the error and submit the request again. All the rules associated with a given policy are logically ANDed together. A -request must match all the policy’s rules to match the policy. +request must match all the policy's rules to match the policy. If you need to express a logical OR operation between rules, then do this by creating multiple policies with the same action. diff --git a/doc/source/reference/introduction.rst b/doc/source/reference/introduction.rst index c5d1f1b00d..21cd3262d9 100644 --- a/doc/source/reference/introduction.rst +++ b/doc/source/reference/introduction.rst @@ -62,7 +62,7 @@ In accomplishing its role, Octavia makes use of other OpenStack projects: configuration and management. Octavia is designed to interact with the components listed previously. In each -case, we’ve taken care to define this interaction through a driver interface. +case, we've taken care to define this interaction through a driver interface. That way, external components can be swapped out with functionally-equivalent replacements— without having to restructure major components of Octavia. For example, if you use an SDN solution other than Neutron in your environment, it @@ -97,7 +97,7 @@ terms as they are defined and used within the context of the Octavia project and Neutron LBaaS version 2. This glossary is available here: :doc:`glossary` If you are familiar with Neutron LBaaS version 1 terms and usage, it is -especially important for you to understand how the meanings of the terms “VIP," +especially important for you to understand how the meanings of the terms "VIP," "load balancer," and "load balancing," have changed in Neutron LBaaS version 2. Our use of these terms should remain consistent with the :doc:`glossary` diff --git a/specs/version0.9/active-active-topology.rst b/specs/version0.9/active-active-topology.rst index 4deca38c4c..28f3cc6532 100644 --- a/specs/version0.9/active-active-topology.rst +++ b/specs/version0.9/active-active-topology.rst @@ -373,7 +373,7 @@ Network driver changes ~~~~~~~~~~~~~~~~~~~~~~ * Support the creation, connection, and configuration of the various - networks and interfaces as described in ‘high-level topology' diagram. + networks and interfaces as described in 'high-level topology' diagram. * Adding a new loadbalancer requires attaching the Distributor to the loadbalancer's front-end network, adding a VIP port to the Distributor, diff --git a/specs/version1.1/enable-provider-driver.rst b/specs/version1.1/enable-provider-driver.rst index 595e74dd7a..1e585d4b75 100644 --- a/specs/version1.1/enable-provider-driver.rst +++ b/specs/version1.1/enable-provider-driver.rst @@ -776,12 +776,12 @@ Member Existing members are matched based on address/port combination. For example, assume a pool currently has two members. These members have the - following address/port combinations: ‘192.0.2.15:80’ and ‘192.0.2.16:80’. + following address/port combinations: '192.0.2.15:80' and '192.0.2.16:80'. Now assume a PUT request is made that includes members with address/port - combinations: ‘192.0.2.16:80’ and ‘192.0.2.17:80’. The member ‘192.0.2.15:80’ - will be deleted because it was not in the request. The member ‘192.0.2.16:80’ + combinations: '192.0.2.16:80' and '192.0.2.17:80'. The member '192.0.2.15:80' + will be deleted because it was not in the request. The member '192.0.2.16:80' will be updated to match the request data for that member, because it was - matched. The member ‘192.0.2.17:80’ will be created, because no such member + matched. The member '192.0.2.17:80' will be created, because no such member existed. The members will be in the ``PENDING_CREATE``, ``PENDING_UPDATE``, or diff --git a/tox.ini b/tox.ini index 5c7b8bfe31..99ce2fd289 100644 --- a/tox.ini +++ b/tox.ini @@ -125,7 +125,7 @@ show-source = true builtins = _ exclude = .venv,.git,.tox,dist,doc,*lib/python*,*egg,build import-order-style = pep8 -# [H106]: Don’t put vim configuration in source files +# [H106]: Don't put vim configuration in source files # [H203]: Use assertIs(Not)None to check for None # [H904] Delay string interpolations at logging calls. enable-extensions=H106,H203,H904