diff --git a/doc/source/userdoc/statuses.rst b/doc/source/userdoc/statuses.rst index 40785e1b..c723073a 100644 --- a/doc/source/userdoc/statuses.rst +++ b/doc/source/userdoc/statuses.rst @@ -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.