← Back to branch summary

~ubuntu-branches/ubuntu/vivid/sahara/vivid-proposed

« back to all changes in this revision

Viewing changes to doc/source/userdoc/statuses.rst

  • Committer: Package Import Robot
  • Author(s): Thomas Goirand
  • Date: 2014-09-24 16:34:46 UTC
  • Revision ID: package-import@ubuntu.com-20140924163446-8gu3zscu5e3n9lr2
Tags: upstream-2014.2~b3
Import upstream version 2014.2~b3

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/source/userdoc/statuses.rst
 
1
Sahara Cluster Statuses Overview
 
2
================================
 
3
 
 
4
All Sahara Cluster operations are performed in multiple steps. A Cluster object
 
5
has a ``Status`` attribute which changes when Sahara finishes one step of
 
6
operations and starts another one.
 
7
 
 
8
Sahara supports three types of Cluster operations:
 
9
 * Create a new Cluster
 
10
 * Scale/Shrink an existing Cluster
 
11
 * Delete an existing Cluster
 
12
 
 
13
Creating a new Cluster
 
14
----------------------
 
15
 
 
16
1. Validating
 
17
~~~~~~~~~~~~~
 
18
 
 
19
Before performing any operations with OpenStack environment, Sahara validates
 
20
user input.
 
21
 
 
22
There are two types of validations, that are done:
 
23
 * Check that a request contains all necessary fields and request does not violate
 
24
any constraints like unique naming and etc.
 
25
 * Plugin check (optional). The provisioning Plugin may also perform any specific checks like Cluster topology validation.
 
26
 
 
27
If any of validations fails, the Cluster will still be kept in database with ``Error``
 
28
status.
 
29
 
 
30
2. InfraUpdating
 
31
~~~~~~~~~~~~~~~~
 
32
 
 
33
This status means that the Provisioning plugin performs some infrastructural updates.
 
34
 
 
35
3. Spawning
 
36
~~~~~~~~~~~
 
37
 
 
38
Sahara sends requests to OpenStack for all resources to be created:
 
39
 * VMs
 
40
 * Volumes
 
41
 * Floating IPs (if Sahara is configured to use Floating IPs)
 
42
 
 
43
It takes some time for OpenStack to schedule all required VMs and Volumes,
 
44
so Sahara wait until all of them are in ``Active`` state.
 
45
 
 
46
4. Waiting
 
47
~~~~~~~~~~
 
48
 
 
49
Sahara waits while VMs' operating systems boot up and all internal infrastructure
 
50
components like networks and volumes are attached and ready to use.
 
51
 
 
52
5. Preparing
 
53
~~~~~~~~~~~~
 
54
 
 
55
Sahara preparers a Cluster for starting. This step includes generating ``/etc/hosts``
 
56
file, so that all instances could access each other by a hostname. Also Sahara
 
57
updates ``authorized_keys`` file on each VM, so that communications could be done
 
58
without passwords.
 
59
 
 
60
6. Configuring
 
61
~~~~~~~~~~~~~~
 
62
 
 
63
Sahara pushes service configurations to VMs. Both XML based configurations and
 
64
environmental variables are set on this step.
 
65
 
 
66
7. Starting
 
67
~~~~~~~~~~~
 
68
 
 
69
Sahara is starting Hadoop services on Cluster's VMs.
 
70
 
 
71
8. Active
 
72
~~~~~~~~~
 
73
 
 
74
Active status means that a Cluster has started successfully and is ready to run Jobs.
 
75
 
 
76
 
 
77
Scaling/Shrinking an existing Cluster
 
78
-------------------------------------
 
79
 
 
80
1. Validating
 
81
~~~~~~~~~~~~~
 
82
 
 
83
Sahara checks the scale/shrink request for validity. The Plugin method called
 
84
for performing Plugin specific checks is different from creation validation method.
 
85
 
 
86
2. Scaling
 
87
~~~~~~~~~~
 
88
 
 
89
Sahara performs database operations updating all affected existing Node Groups
 
90
and creating new ones.
 
91
 
 
92
3. Adding Instances
 
93
~~~~~~~~~~~~~~~~~~~
 
94
 
 
95
State similar to ``Spawning`` while Custer creation. Sahara adds required amount
 
96
of VMs to existing Node Groups and creates new Node Groups.
 
97
 
 
98
4. Configuring
 
99
~~~~~~~~~~~~~~
 
100
 
 
101
State similar to ``Configuring`` while Cluster creation. New instances are being configured
 
102
in the same manner as already existing ones. Existing Cluster VMs are also updated
 
103
with a new ``/etc/hosts`` file.
 
104
 
 
105
5. Decommissioning
 
106
~~~~~~~~~~~~~~~~~~
 
107
 
 
108
Sahara stops Hadoop services on VMs that will be deleted from a Cluster.
 
109
Decommissioning Data Node may take some time because Hadoop rearranges data replicas
 
110
around the Cluster, so that no data will be lost after tht VM is deleted.
 
111
 
 
112
6. Deleting Instances
 
113
~~~~~~~~~~~~~~~~~~~~~
 
114
 
 
115
Sahara sends requests to OpenStack to release unneeded resources:
 
116
 * VMs
 
117
 * Volumes
 
118
 * Floating IPs (if they are used)
 
119
 
 
120
7. Active
 
121
~~~~~~~~~
 
122
 
 
123
The same ``Active`` as after Cluster creation.
 
124
 
 
125
 
 
126
Deleting an existing Cluster
 
127
----------------------------
 
128
 
 
129
1. Deleting
 
130
~~~~~~~~~~~
 
131
 
 
132
The only step, that releases all Cluster's resources and removes it form database.
 
133
 
 
134
Error State
 
135
-----------
 
136
 
 
137
If Cluster creation fails, the Cluster will get into ``Error`` state.
 
138
This state means the Cluster may not be able to perform any operations normally.
 
139
This cluster will stay in database until it is manually deleted. The reason of
 
140
failure may be found in Sahara logs.
 
141
 
 
142
 
 
143
If an error occurs during ``Adding Instances`` operation, Sahara will first
 
144
try to rollback this operation. If rollback is impossible or fails itself, then
 
145
the Cluster will also get into ``Error`` state.