Update words as of word-choice list in contributor guide
Change life cycle to lifecycle a SQL to an SQL Openstack to OpenStack Change-Id: I0fd46b8b7b7b6e1f32e8575ca65e2dd767315f64
This commit is contained in:
parent
f271c836f8
commit
13410e5935
|
@ -64,7 +64,7 @@ data store version.
|
|||
|
||||
.. important::
|
||||
|
||||
If you have a guest image that was created with an Openstack version
|
||||
If you have a guest image that was created with an OpenStack version
|
||||
before Kilo, modify the guest agent init script for the guest image to
|
||||
read the configuration files from the directory ``/etc/trove/conf.d``.
|
||||
|
||||
|
|
|
@ -37,7 +37,7 @@ Each share driver supports one or two of possible back end modes that can be
|
|||
configured in the ``manila.conf`` file. The configuration option
|
||||
``driver_handles_share_servers`` in the ``manila.conf`` file sets the share
|
||||
servers mode or no share servers mode, and defines the driver mode for share
|
||||
storage life cycle management:
|
||||
storage lifecycle management:
|
||||
|
||||
+------------------+-------------------------------------+--------------------+
|
||||
| Mode | Config option | Description |
|
||||
|
|
|
@ -5,7 +5,7 @@ Manage and unmanage share
|
|||
=========================
|
||||
|
||||
To ``manage`` a share means that an administrator rather than a share driver
|
||||
manages the storage life cycle. This approach is appropriate when an
|
||||
manages the storage lifecycle. This approach is appropriate when an
|
||||
administrator already has the custom non-manila share with its size, shared
|
||||
file system protocol, export path and so on, and administrator wants to
|
||||
register it in the Shared File System service.
|
||||
|
@ -18,7 +18,7 @@ File Systems service. An administrator can manage the custom share back.
|
|||
Unmanage share
|
||||
--------------
|
||||
You can ``unmanage`` a share, to unregister it from the Shared File System
|
||||
service, and take manual control on share life cycle. The ``unmanage``
|
||||
service, and take manual control on share lifecycle. The ``unmanage``
|
||||
operation is not supported for shares that were created on top of share servers
|
||||
and created with share networks), so share service should have option
|
||||
``driver_handles_share_servers = False`` in its configuration. You can unmanage
|
||||
|
|
|
@ -13,7 +13,7 @@ OpenStack.
|
|||
|
||||
The Shared File Systems service may need a network resource provisioning if
|
||||
share service with specified driver works in mode, when a share driver manages
|
||||
life cycle of share servers on its own. This behavior is defined by a flag
|
||||
lifecycle of share servers on its own. This behavior is defined by a flag
|
||||
``driver_handles_share_servers`` in share service configuration. When
|
||||
``driver_handles_share_servers`` is set to ``True``, a share driver will be
|
||||
called to create share servers for shares using information provided within a
|
||||
|
|
|
@ -27,10 +27,10 @@ filter back ends. Administrators can create share types with these extra
|
|||
specifications for the back ends filtering:
|
||||
|
||||
- ``driver_handles_share_servers``. Required. Defines the driver mode for share
|
||||
server life cycle management. Valid values are ``true``/``1`` and
|
||||
server lifecycle management. Valid values are ``true``/``1`` and
|
||||
``false``/``0``.
|
||||
Set to True when the share driver can manage, or handle, the share server
|
||||
life cycle.
|
||||
lifecycle.
|
||||
Set to False when an administrator, rather than a share driver, manages
|
||||
the bare metal storage with some net interface instead of the presence
|
||||
of the share servers.
|
||||
|
|
|
@ -18,7 +18,7 @@ SLA.
|
|||
Consider the ability to upgrade the infrastructure. As demand for
|
||||
network resources increase, operators add additional IP address blocks
|
||||
and add additional bandwidth capacity. In addition, consider managing
|
||||
hardware and software life cycle events, for example upgrades,
|
||||
hardware and software lifecycle events, for example upgrades,
|
||||
decommissioning, and outages, while avoiding service interruptions for
|
||||
tenants.
|
||||
|
||||
|
|
|
@ -44,7 +44,7 @@ will be allocated in a way that makes the most efficient use of the
|
|||
available hardware. Bin packing also requires a common hardware design,
|
||||
with all hardware nodes within a compute resource pool sharing a common
|
||||
processor, memory, and storage layout. This makes it easier to deploy,
|
||||
support, and maintain nodes throughout their life cycle.
|
||||
support, and maintain nodes throughout their lifecycle.
|
||||
|
||||
An overcommit ratio is the ratio of available virtual resources to
|
||||
available physical resources. This ratio is configurable for CPU and
|
||||
|
|
|
@ -23,7 +23,7 @@ SLA.
|
|||
Consider the ability to upgrade the infrastructure. As demand for
|
||||
network resources increase, operators add additional IP address blocks
|
||||
and add additional bandwidth capacity. In addition, consider managing
|
||||
hardware and software life cycle events, for example upgrades,
|
||||
hardware and software lifecycle events, for example upgrades,
|
||||
decommissioning, and outages, while avoiding service interruptions for
|
||||
tenants.
|
||||
|
||||
|
|
|
@ -11,7 +11,7 @@ Input-Output requirements
|
|||
expected performance levels. If these tests include details, then
|
||||
the resulting data can help model behavior and results during
|
||||
different workloads. Running scripted smaller benchmarks during the
|
||||
life cycle of the architecture helps record the system health at
|
||||
lifecycle of the architecture helps record the system health at
|
||||
different points in time. The data from these scripted benchmarks
|
||||
assist in future scoping and gaining a deeper understanding of an
|
||||
organization's needs.
|
||||
|
|
|
@ -904,7 +904,7 @@
|
|||
<glossdef>
|
||||
<para>The storage method used by the Identity service catalog service
|
||||
to store and retrieve information about API endpoints that are
|
||||
available to the client. Examples include a SQL database, LDAP
|
||||
available to the client. Examples include an SQL database, LDAP
|
||||
database, or KVS back end.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
@ -1972,7 +1972,7 @@
|
|||
|
||||
<glossdef>
|
||||
<para>The Compute component that runs on each compute node and manages
|
||||
the VM instance life cycle, including run, reboot, terminate,
|
||||
the VM instance lifecycle, including run, reboot, terminate,
|
||||
attach/detach volumes, and so on. Provided by the <systemitem
|
||||
class="service">nova-compute</systemitem> daemon.</para>
|
||||
</glossdef>
|
||||
|
|
|
@ -39,7 +39,7 @@ Ephemeral Disk GB
|
|||
the ephemeral partition. If unspecified, the value
|
||||
is 0 by default.
|
||||
Ephemeral disks offer machine local disk storage
|
||||
linked to the life cycle of a VM instance. When a
|
||||
linked to the lifecycle of a VM instance. When a
|
||||
VM is terminated, all data on the ephemeral disk
|
||||
is lost. Ephemeral disks are not included in any
|
||||
snapshots.
|
||||
|
|
|
@ -49,7 +49,7 @@ Create flavors
|
|||
is 0 by default.
|
||||
|
||||
Ephemeral disks offer machine local
|
||||
disk storage linked to the life cycle
|
||||
disk storage linked to the lifecycle
|
||||
of a VM instance. When a VM is
|
||||
terminated, all data on the ephemeral
|
||||
disk is lost. Ephemeral disks are not
|
||||
|
|
|
@ -14,7 +14,7 @@ Meter
|
|||
ongoing performance, such as the CPU utilization
|
||||
for an instance. Meters exist for each type of
|
||||
resource. For example, a separate ``cpu_util``
|
||||
meter exists for each instance. The life cycle
|
||||
meter exists for each instance. The lifecycle
|
||||
of a meter is decoupled from the existence of
|
||||
its related resource. The meter persists after
|
||||
the resource goes away.
|
||||
|
|
|
@ -116,15 +116,15 @@ number of commands.
|
|||
$ heat resource-show mystack WikiDatabase
|
||||
|
||||
- Some resources have associated metadata which can change throughout
|
||||
the life cycle of a resource. Show the metadata by running the
|
||||
the lifecycle of a resource. Show the metadata by running the
|
||||
following command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ heat resource-metadata mystack WikiDatabase
|
||||
|
||||
- A series of events is generated during the life cycle of a stack. To
|
||||
display life cycle events, run the following command:
|
||||
- A series of events is generated during the lifecycle of a stack. To
|
||||
display lifecycle events, run the following command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
Loading…
Reference in New Issue