[sahara doc fix] update the statuses.rst in userdoc

Change-Id: Ie29c5cfc6ff42712e959629f631ebec3e7132e4a
This commit is contained in:
luhuichun 2015-08-31 23:14:52 +08:00
parent 6b7e3a0271
commit 7012efb1ee

View File

@ -4,7 +4,7 @@ Sahara Cluster Statuses Overview
All Sahara Cluster operations are performed in multiple steps. A Cluster object
has a ``Status`` attribute which changes when Sahara finishes one step of
operations and starts another one. Also a Cluster object has a ``Status description``
attribute which changes each time when some error with the Cluster occurs.
attribute which changes whenever Cluster errors occur.
Sahara supports three types of Cluster operations:
* Create a new Cluster
@ -23,17 +23,17 @@ user input.
There are two types of validations, that are done:
* Check that a request contains all necessary fields and that the request does not violate
any constraints like unique naming, etc.
* Plugin check (optional). The provisioning Plugin may also perform any specific checks like Cluster topology validation.
* Plugin check (optional). The provisioning Plugin may also perform any specific checks like a Cluster topology validation check.
If any of the validations fails during creating, the Cluster will
If any of the validations fails during creating, the Cluster object will
still be kept in the database with an ``Error`` status. If any validations fails during scaling the ``Active`` Cluster, it will be
kept with an ``Active`` status.
In both cases status description will contain message about the reasons of failure.
In both cases status description will contain error messages about the reasons of failure.
2. InfraUpdating
~~~~~~~~~~~~~~~~
This status means that the Provisioning plugin performs some infrastructural updates.
This status means that the Provisioning plugin is performing some infrastructure updates.
3. Spawning
~~~~~~~~~~~
@ -44,7 +44,7 @@ Sahara sends requests to OpenStack for all resources to be created:
* Floating IPs (if Sahara is configured to use Floating IPs)
It takes some time for OpenStack to schedule all the required VMs and Volumes,
so Sahara will wait until all of them are in an ``Active`` state.
so sahara will wait until all of the VMs are in an ``Active`` state.
4. Waiting
~~~~~~~~~~
@ -57,13 +57,13 @@ components like networks and volumes are attached and ready to use.
Sahara prepares a Cluster for starting. This step includes generating the ``/etc/hosts``
file, so that all instances can access each other by a hostname. Also Sahara
updates the ``authorized_keys`` file on each VM, so that communication can be done
without passwords.
updates the ``authorized_keys`` file on each VM, so that VMs can communicate without
passwords.
6. Configuring
~~~~~~~~~~~~~~
Sahara pushes service configurations to VMs. Both XML based configurations and
Sahara pushes service configurations to VMs. Both XML and JSON based configurations and
environmental variables are set on this step.
7. Starting
@ -74,7 +74,7 @@ Sahara is starting Hadoop services on Cluster's VMs.
8. Active
~~~~~~~~~
Active status means that a Cluster has started successfully and is ready to run Jobs.
Active status means that a Cluster has started successfully and is ready to run EDP Jobs.
Scaling/Shrinking an existing Cluster
@ -84,25 +84,25 @@ Scaling/Shrinking an existing Cluster
~~~~~~~~~~~~~
Sahara checks the scale/shrink request for validity. The Plugin method called
for performing Plugin specific checks is different from creation validation method.
for performing Plugin specific checks is different from the validation method in creation.
2. Scaling
~~~~~~~~~~
Sahara performs database operations updating all affected existing Node Groups
and creating new ones.
and creating new ones to join the existing Node Groups.
3. Adding Instances
~~~~~~~~~~~~~~~~~~~
State similar to ``Spawning`` while Custer creation. Sahara adds required amount
of VMs to existing Node Groups and creates new Node Groups.
Status is similar to ``Spawning`` in Custer creation. Sahara adds required amount
of VMs to the existing Node Groups and creates new Node Groups.
4. Configuring
~~~~~~~~~~~~~~
State similar to ``Configuring`` while Cluster creation. New instances are being configured
in the same manner as already existing ones. Existing Cluster VMs are also updated
Status is similar to ``Configuring`` in Cluster creation. New instances are being configured
in the same manner as already existing ones. The VMs in the existing Cluster are also updated
with a new ``/etc/hosts`` file.
5. Decommissioning
@ -110,7 +110,7 @@ with a new ``/etc/hosts`` file.
Sahara stops Hadoop services on VMs that will be deleted from a Cluster.
Decommissioning a Data Node may take some time because Hadoop rearranges data replicas
around the Cluster, so that no data will be lost after that VM is deleted.
around the Cluster, so that no data will be lost after that Data Node is deleted.
6. Deleting Instances
~~~~~~~~~~~~~~~~~~~~~
@ -123,7 +123,7 @@ Sahara sends requests to OpenStack to release unneeded resources:
7. Active
~~~~~~~~~
The same ``Active`` as after Cluster creation.
The same ``Active`` status as after Cluster creation.
Deleting an existing Cluster
@ -137,14 +137,14 @@ The only step, that releases all Cluster's resources and removes it from the dat
Error State
-----------
If the Cluster creation fails, the Cluster will get into an ``Error`` state.
This state means the Cluster may not be able to perform any operations normally.
If the Cluster creation fails, the Cluster will enter the ``Error`` state.
This status means the Cluster may not be able to perform any operations normally.
This cluster will stay in the database until it is manually deleted. The reason for
failure may be found in the Sahara logs. Also status description will contain short
information about reasons of failure.
failure may be found in the sahara logs. Also, the status description will contain
information about the error.
If an error occurs during the ``Adding Instances`` operation, Sahara will first
try to rollback this operation. If a rollback is impossible or fails itself, then
the Cluster will also go into an ``Error`` state. If a rollback was successful, Cluster will get into an ``Active`` state
and status description will contain short message about the reasons of ``Adding Instances`` failure.
and status description will contain a short message about the reason of ``Adding Instances`` failure.