openstack/nova
Code Issues Proposed changes

Fix API Guide doc

Browse Source 
* typos
* reduntant words
* reworded sentences for clarity

Closes-bug: #1545748

Change-Id: I0700d04de38b34cf13988490873b8c34dad1005b
This commit is contained in:
Waldemar Znoinski
2016-02-15 14:42:02 +00:00
parent c20fbc44a9
commit fdd8f0f91e
10 changed files with 97 additions and 96 deletions
Download Patch File Download Diff File Expand all files Collapse all files

81
api-guide/source/server_concepts.rst
View File

@@ -15,7 +15,7 @@ help user to understand the difference.
You can filter the list of servers by image, flavor, name, and status
through the respective query parameters.
Servers contain a status attribute that indicates the current server
Server contains a status attribute that indicates the current server
state. You can filter on the server status when you complete a list
servers request. The server status is returned in the response body. The
server status is one of the following values:
@@ -24,7 +24,7 @@ server status is one of the following values:
- ``ACTIVE``: The server is active.
- ``BUILD``: The server has not finished the original build process.
- ``BUILD``: The server has not yet finished the original build process.
- ``DELETED``: The server is deleted.
@@ -34,7 +34,7 @@ server status is one of the following values:
pulling the power plug on a physical server, plugging it back in, and
rebooting it.
- ``MIGRATING``: The server is under migrating. This is caused by a
- ``MIGRATING``: The server is migrating. This is caused by a
live migration (moving a server that is active) action.
- ``PASSWORD``: The password is being reset on the server.
@@ -61,7 +61,7 @@ server status is one of the following values:
- ``SHELVED_OFFLOADED``: The shelved server is offloaded (removed from the
compute host) and it needs unshelved action to be used again.
- ``SHUTOFF``: The virtual machine (VM) was powered down by the user,
- ``SHUTOFF``: The server was powered down by the user,
but not through the OpenStack Compute API. For example, the user
issued a ``shutdown -h`` command from within the server. If
the OpenStack Compute manager detects that the VM was powered down,
@@ -79,8 +79,8 @@ server status is one of the following values:
necessity. This status appears for only the following hypervisors:
XenServer/XCP, KVM, and ESXi. Administrative users may suspend a
server if it is infrequently used or to perform system maintenance.
When you suspend a server, its VM state is stored on disk, all
memory is written to disk, and the virtual machine is stopped.
When you suspend a server, its state is stored on disk, all
memory is written to disk, and the server is stopped.
Suspending a server is similar to placing a device in hibernation;
memory and vCPUs become available to create other servers.
@@ -381,7 +381,7 @@ be used and interpreted by nova.
}
Server actions
~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~
- **Reboot**
@@ -405,7 +405,7 @@ Server actions
listed in an 'ACTIVE' state forever.
Evacuate is a work around for this that lets an administrator
forceably rebuild these zombie servers on another node. It makes
forcibly rebuild these servers on another node. It makes
no guarantees that the host was actually down, so fencing is
left as an exercise to the deployer.
@@ -421,9 +421,9 @@ Server actions
Confirm resize action will delete the old server in the virt layer.
The spawned server in the virt layer will be used from then on.
on the contrary, Revert resize action will delete the new server
spawned in the virt layer and revert all changes, the original server
will still be used from then on.
On the contrary, Revert resize action will delete the new server
spawned in the virt layer and revert all changes. The original server
will be used from then on.
Also, there is a periodic task configured by configuration option
resize_confirm_window(in seconds), if this value is not 0, nova compute
@@ -454,7 +454,7 @@ Server actions
You can store the current state of the server root disk to be saved
and uploaded back into the glance image repository.
Then the server can later be booted again using this saved image.
Then a server can later be booted again using this saved image.
- **Backup**
@@ -464,11 +464,11 @@ Server actions
- **Start**
Power on an server.
Power on the server.
- **Stop**
Power off an server.
Power off the server.
- **Delete**, **Restore**
@@ -486,7 +486,7 @@ Server actions
- **Shelve**, **Shelve offload**, **Unshelve**
Shelving an server indicates it will not be needed for some time and may be
Shelving a server indicates it will not be needed for some time and may be
temporarily removed from the hypervisors. This allows its resources to
be freed up for use by someone else.
@@ -494,14 +494,15 @@ Server actions
server will be removed from the hypervisor immediately after shelve operation;
Otherwise, the resource will be kept for the value of 'shelved_offload_time'
(in seconds) so that during the time period the unshelve action will be faster,
then the periodic task will remove the server from hypervisor. Set the option
'shelved_offload_time' to -1 make it never offload.
then the periodic task will remove the server from hypervisor after
'shelved_offload_time' time passes. Set the option 'shelved_offload_time'
to -1 make it never offload.
Shelve will power off the given server and take a snapshot if it is booted
from image. The server can then be offloaded from the compute host and its
resources deallocated. Offloading is done immediately if booted from volume,
but if booted from image the offload can be delayed for some time or
indefinitely, leaving the image on disk and the resources still allocated.
infinitely, leaving the image on disk and the resources still allocated.
Shelve offload is used to explicitly remove a shelved server that has been
left on a host. This action can only be used on a shelved server and is
@@ -525,23 +526,23 @@ Server actions
The rescue operation starts a server in a special configuration whereby
it is booted from a special root disk image. This enables the tenant to try
and restore a broken vitrual machine.
and restore a broken guest system.
Unrescue is the reverse action of Rescue, the server spawned from the special
Unrescue is the reverse action of Rescue. The server spawned from the special
root image will be deleted.
- **Set administrator password**
Set the root/administrator password for the given server, it uses an
optional installed agent to inject the administrator password.
Sets the root/administrator password for the given server. It uses an
optionally installed agent to set the administrator password.
- **Migrate**, **Live migrate**
Migrate is usually utilized by administrator, it will move a server to
another host; it utilize the 'resize' action but with same flavor, so during
migration, the server will be power off and rebuilt on another host.
another host; it utilizes the 'resize' action but with same flavor, so during
migration, the server will be powered off and rebuilt on another host.
Live migrate also moves an server from one host to another, but it won't
Live migrate also moves a server from one host to another, but it won't
power off the server in general so the server will not suffer a down time.
Administrators may use this to evacuate servers from a host that needs to
undergo maintenance tasks.
@@ -604,7 +605,7 @@ server interface.
Considerations
~~~~~~~~~~~~~~
The maximum limit refers to the number of bytes in the decoded data
- The maximum limit refers to the number of bytes in the decoded data
and not the number of characters in the encoded data.
- The maximum number of file path/content pairs that you can supply is
@@ -615,13 +616,13 @@ Considerations
guaranteed to apply to all images in the deployment. Providers can
set additional per-image personality limits.
The file injection might not occur until after the server is built and
booted.
- The file injection might not occur until after the server is built and
booted.
After file injection, personality files are accessible by only system
administrators. For example, on Linux, all files have root and the root
group as the owner and group owner, respectively, and allow user and
group read access only (octal 440).
- After file injection, personality files are accessible by only system
administrators. For example, on Linux, all files have root and the root
group as the owner and group owner, respectively, and allow user and
group read access only (octal 440).
Server access addresses
~~~~~~~~~~~~~~~~~~~~~~~
@@ -710,19 +711,19 @@ a cloud:
- **Host maintenance**
If a compute host is to be removed from the cloud all its servers
will need to moved to other hosts. In this case it is normal for
will need to be moved to other hosts. In this case it is normal for
the rest of the cloud to absorb the work load, redistributing
the servers by rescheduling them.
To prepare the host it will be disabled so it does not receive
any further servers. Then each server will be migrated to a new
host by cold or live migration, depending on the state of the
server. When complete, the host is free to be removed.
server. When complete, the host is ready to be removed.
- **Rolling updates**
Often it is necessary to perform an update on all compute hosts
that requires them to be rebooted. In this case it is not
which requires them to be rebooted. In this case it is not
strictly necessary to move inactive servers because they
will be available after the reboot. However, active servers would
be impacted by the reboot. Live migration will allow them to
@@ -751,7 +752,7 @@ a cloud:
Migrating a server is not normally a choice that is available to
the cloud user because the user is not normally aware of compute
hosts. Management of the cloud and how servers are provisioned
in it is the sole responsibility of the cloud operator.
in it is the responsibility of the cloud operator.
Recover from a failed compute host
----------------------------------
@@ -793,7 +794,7 @@ User resizes server to get more resources
Sometimes a user may want to change the flavor of a server, e.g. change
the quantity of cpus, disk, memory or any other resource. This is done
by rebuilding the server with a new flavor. As the server is being
by restarting the server with a new flavor. As the server is being
moved, it is normal to reschedule the server to another host
(although resize to the same host is an option for the operator).
@@ -805,12 +806,12 @@ the server is started again.
After the resize operation, when the user is happy their server is
working correctly after the resize, the user calls Confirm Resize.
This deletes the backup server that was kept on the source host.
This deletes the 'before-the-resize' server that was kept on the source host.
Alternatively, the user can call Revert Resize to delete the new
resized server, and restore the back up that was stored on the source
resized server and restore the old that was stored on the source
host. If the user does not manually confirm the resize within a
configured time period, the resize is automatically confirmed, to
free up the space the backup is using on the source host.
free up the space the old is using on the source host.
As with shelving, resize provides the cloud operator with an
opportunity to redistribute work loads across the cloud according