don't hyphenate "highly {available,scalable}"
The majority of occurrences of "highly available" in the manuals are not hyphenated, but a minority are, which is inconsistent. Similarly with "highly scalable". According to https://www.quora.com/Should-highly-respected-be-hyphenated-Is-there-a-general-rule-about-hyphenation the rule is that words should be hyphenated only to avoid confusion, but in the case of "highly available OpenStack" or similar, it is clear that "highly" modifies "available" rather than "OpenStack", because "highly OpenStack" makes no sense. Therefore we remove the hyphens from the minority and go with the majority. Change-Id: Ifdd029b1c6bfbfc1f912edd8ed04f6c1148e36d0
This commit is contained in:
parent
963fa1225d
commit
420fb6ff90
@ -12,7 +12,7 @@ for overcommitting of these. In a similar manner, rather than exposing the
|
||||
individual types of network devices available on hosts, generic
|
||||
software-powered network ports are provided. These features are designed to
|
||||
allow high resource utilization and allows the service to provide a generic
|
||||
cost-effective and highly-scalable cloud upon which to build applications.
|
||||
cost-effective and highly scalable cloud upon which to build applications.
|
||||
|
||||
This abstraction is beneficial for most workloads. However, there are some
|
||||
workloads where determinism and per-instance performance are important, if
|
||||
|
@ -96,7 +96,7 @@ Initialize and configure the database
|
||||
-------------------------------------
|
||||
|
||||
Database-backed sessions are scalable, persistent, and can be made
|
||||
high-concurrency and highly-available.
|
||||
high-concurrency and highly available.
|
||||
|
||||
However, database-backed sessions are one of the slower session storages
|
||||
and incur a high overhead under heavy usage. Proper configuration of
|
||||
|
@ -1167,7 +1167,7 @@ D
|
||||
|
||||
distributed virtual router (DVR)
|
||||
|
||||
Mechanism for highly-available multi-host routing when using
|
||||
Mechanism for highly available multi-host routing when using
|
||||
OpenStack Networking (neutron).
|
||||
|
||||
Django
|
||||
@ -2330,7 +2330,7 @@ M
|
||||
OpenStack project that aims to produce an OpenStack
|
||||
messaging service that affords a variety of distributed
|
||||
application patterns in an efficient, scalable and
|
||||
highly-available manner, and to create and maintain associated
|
||||
highly available manner, and to create and maintain associated
|
||||
Python libraries and documentation. The code name for the
|
||||
project is zaqar.
|
||||
|
||||
|
@ -52,7 +52,7 @@ The Message service provides the following key features:
|
||||
filters.
|
||||
* Efficient reference implementation with an eye toward low latency and high
|
||||
throughput (dependent on back end).
|
||||
* Highly-available and horizontally scalable.
|
||||
* Highly available and horizontally scalable.
|
||||
* Support for subscriptions to queues. Several notification types are
|
||||
available:
|
||||
|
||||
|
@ -46,6 +46,6 @@ for hardware acceleration of nested VMs.
|
||||
|
||||
.. note::
|
||||
|
||||
When installing highly-available OpenStack on VMs,
|
||||
When installing highly available OpenStack on VMs,
|
||||
be sure that your hypervisor permits promiscuous mode
|
||||
and disables MAC address filtering on the external network.
|
||||
|
@ -2,7 +2,7 @@
|
||||
Install operating system on each node
|
||||
=====================================
|
||||
|
||||
The first step in setting up your highly-available OpenStack cluster
|
||||
The first step in setting up your highly available OpenStack cluster
|
||||
is to install the operating system on each node.
|
||||
Follow the instructions in the OpenStack Installation Guides:
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
|
||||
==========================================
|
||||
Overview of highly-available compute nodes
|
||||
Overview of highly available compute nodes
|
||||
==========================================
|
||||
|
@ -1,5 +1,5 @@
|
||||
========================================
|
||||
Overview of highly-available controllers
|
||||
Overview of highly available controllers
|
||||
========================================
|
||||
|
||||
OpenStack is a set of multiple services exposed to the end users
|
||||
@ -9,7 +9,7 @@ where all the components are running are often called controllers.
|
||||
This modular OpenStack architecture allows to duplicate all the
|
||||
components and run them on different controllers.
|
||||
By making all the components redundant it is possible to make
|
||||
OpenStack highly-available.
|
||||
OpenStack highly available.
|
||||
|
||||
In general we can divide all the OpenStack components into three categories:
|
||||
|
||||
|
@ -9,7 +9,7 @@ environment.
|
||||
Overview
|
||||
~~~~~~~~
|
||||
|
||||
A highly-available environment can be put into place if you require an
|
||||
A highly available environment can be put into place if you require an
|
||||
environment that can scale horizontally, or want your cloud to continue
|
||||
to be operational in case of node failure. This example architecture has
|
||||
been written based on the current default feature set of OpenStack
|
||||
|
Loading…
Reference in New Issue
Block a user