root / doc / design-2.1.rst @ 5b18ff3b
History | View | Annotate | Download (8 kB)
1 |
================= |
---|---|
2 |
Ganeti 2.1 design |
3 |
================= |
4 |
|
5 |
This document describes the major changes in Ganeti 2.1 compared to |
6 |
the 2.0 version. |
7 |
|
8 |
The 2.1 version will be a relatively small release. Its main aim is to avoid |
9 |
changing too much of the core code, while addressing issues and adding new |
10 |
features and improvements over 2.0, in a timely fashion. |
11 |
|
12 |
.. contents:: :depth: 3 |
13 |
|
14 |
Objective |
15 |
========= |
16 |
|
17 |
Ganeti 2.1 will add features to help further automatization of cluster |
18 |
operations, further improbe scalability to even bigger clusters, and make it |
19 |
easier to debug the Ganeti core. |
20 |
|
21 |
Background |
22 |
========== |
23 |
|
24 |
Overview |
25 |
======== |
26 |
|
27 |
Detailed design |
28 |
=============== |
29 |
|
30 |
As for 2.0 we divide the 2.1 design into three areas: |
31 |
|
32 |
- core changes, which affect the master daemon/job queue/locking or all/most |
33 |
logical units |
34 |
- logical unit/feature changes |
35 |
- external interface changes (eg. command line, os api, hooks, ...) |
36 |
|
37 |
Core changes |
38 |
------------ |
39 |
|
40 |
Feature changes |
41 |
--------------- |
42 |
|
43 |
Redistribute Config |
44 |
~~~~~~~~~~~~~~~~~~~ |
45 |
|
46 |
Current State and shortcomings |
47 |
++++++++++++++++++++++++++++++ |
48 |
Currently LURedistributeConfig triggers a copy of the updated configuration |
49 |
file to all master candidates and of the ssconf files to all nodes. There are |
50 |
other files which are maintained manually but which are important to keep in |
51 |
sync. These are: |
52 |
|
53 |
- rapi SSL key certificate file (rapi.pem) (on master candidates) |
54 |
- rapi user/password file rapi_users (on master candidates) |
55 |
|
56 |
Furthermore there are some files which are hypervisor specific but we may want |
57 |
to keep in sync: |
58 |
|
59 |
- the xen-hvm hypervisor uses one shared file for all vnc passwords, and copies |
60 |
the file once, during node add. This design is subject to revision to be able |
61 |
to have different passwords for different groups of instances via the use of |
62 |
hypervisor parameters, and to allow xen-hvm and kvm to use an equal system to |
63 |
provide password-protected vnc sessions. In general, though, it would be |
64 |
useful if the vnc password files were copied as well, to avoid unwanted vnc |
65 |
password changes on instance failover/migrate. |
66 |
|
67 |
Optionally the admin may want to also ship files such as the global xend.conf |
68 |
file, and the network scripts to all nodes. |
69 |
|
70 |
Proposed changes |
71 |
++++++++++++++++ |
72 |
|
73 |
RedistributeConfig will be changed to copy also the rapi files, and to call |
74 |
every enabled hypervisor asking for a list of additional files to copy. We also |
75 |
may want to add a global list of files on the cluster object, which will be |
76 |
propagated as well, or a hook to calculate them. If we implement this feature |
77 |
there should be a way to specify whether a file must be shipped to all nodes or |
78 |
just master candidates. |
79 |
|
80 |
This code will be also shared (via tasklets or by other means, if tasklets are |
81 |
not ready for 2.1) with the AddNode and SetNodeParams LUs (so that the relevant |
82 |
files will be automatically shipped to new master candidates as they are set). |
83 |
|
84 |
VNC Console Password |
85 |
~~~~~~~~~~~~~~~~~~~~ |
86 |
|
87 |
Current State and shortcomings |
88 |
++++++++++++++++++++++++++++++ |
89 |
|
90 |
Currently just the xen-hvm hypervisor supports setting a password to connect |
91 |
the the instances' VNC console, and has one common password stored in a file. |
92 |
|
93 |
This doesn't allow different passwords for different instances/groups of |
94 |
instances, and makes it necessary to remember to copy the file around the |
95 |
cluster when the password changes. |
96 |
|
97 |
Proposed changes |
98 |
++++++++++++++++ |
99 |
|
100 |
We'll change the VNC password file to a vnc_password_file hypervisor parameter. |
101 |
This way it can have a cluster default, but also a different value for each |
102 |
instance. The VNC enabled hypervisors (xen and kvm) will publish all the |
103 |
password files in use through the cluster so that a redistribute-config will |
104 |
ship them to all nodes (see the Redistribute Config proposed changes above). |
105 |
|
106 |
The current VNC_PASSWORD_FILE constant will be removed, but its value will be |
107 |
used as the default HV_VNC_PASSWORD_FILE value, thus retaining backwards |
108 |
compatibility with 2.0. |
109 |
|
110 |
The code to export the list of VNC password files from the hypervisors to |
111 |
RedistributeConfig will be shared between the KVM and xen-hvm hypervisors. |
112 |
|
113 |
External interface changes |
114 |
-------------------------- |
115 |
|
116 |
OS API |
117 |
~~~~~~ |
118 |
|
119 |
The OS API of Ganeti 2.0 has been built with extensibility in mind. Since we |
120 |
pass everything as environment variables it's a lot easier to send new |
121 |
information to the OSes without breaking retrocompatibility. This section of |
122 |
the design outlines the proposed extensions to the API and their |
123 |
implementation. |
124 |
|
125 |
API Version Compatibility Handling |
126 |
++++++++++++++++++++++++++++++++++ |
127 |
|
128 |
In 2.1 there will be a new OS API version (eg. 15), which should be mostly |
129 |
compatible with api 10, except for some new added variables. Since it's easy |
130 |
not to pass some variables we'll be able to handle Ganeti 2.0 OSes by just |
131 |
filtering out the newly added piece of information. We will still encourage |
132 |
OSes to declare support for the new API after checking that the new variables |
133 |
don't provide any conflict for them, and we will drop api 10 support after |
134 |
ganeti 2.1 has released. |
135 |
|
136 |
New Environment variables |
137 |
+++++++++++++++++++++++++ |
138 |
|
139 |
Some variables have never been added to the OS api but would definitely be |
140 |
useful for the OSes. We plan to add an INSTANCE_HYPERVISOR variable to allow |
141 |
the OS to make changes relevant to the virtualization the instance is going to |
142 |
use. Since this field is immutable for each instance, the os can tight the |
143 |
install without caring of making sure the instance can run under any |
144 |
virtualization technology. |
145 |
|
146 |
We also want the OS to know the particular hypervisor parameters, to be able to |
147 |
customize the install even more. Since the parameters can change, though, we |
148 |
will pass them only as an "FYI": if an OS ties some instance functionality to |
149 |
the value of a particular hypervisor parameter manual changes or a reinstall |
150 |
may be needed to adapt the instance to the new environment. This is not a |
151 |
regression as of today, because even if the OSes are left blind about this |
152 |
information, sometimes they still need to make compromises and cannot satisfy |
153 |
all possible parameter values. |
154 |
|
155 |
OS Parameters |
156 |
+++++++++++++ |
157 |
|
158 |
Currently we are assisting to some degree of "os proliferation" just to change |
159 |
a simple installation behavior. This means that the same OS gets installed on |
160 |
the cluster multiple times, with different names, to customize just one |
161 |
installation behavior. Usually such OSes try to share as much as possible |
162 |
through symlinks, but this still causes complications on the user side, |
163 |
especially when multiple parameters must be cross-matched. |
164 |
|
165 |
For example today if you want to install debian etch, lenny or squeeze you |
166 |
probably need to install the debootstrap OS multiple times, changing its |
167 |
configuration file, and calling it debootstrap-etch, debootstrap-lenny or |
168 |
debootstrap-squeeze. Furthermore if you have for example a "server" and a |
169 |
"development" environment which installs different packages/configuration files |
170 |
and must be available for all installs you'll probably end up with |
171 |
deboostrap-etch-server, debootstrap-etch-dev, debootrap-lenny-server, |
172 |
debootstrap-lenny-dev, etc. Crossing more than two parameters quickly becomes |
173 |
not manageable. |
174 |
|
175 |
In order to avoid this we plan to make OSes more customizable, by allowing |
176 |
arbitrary flags to be passed to them. These will be special "OS parameters" |
177 |
which will be handled by Ganeti mostly as hypervisor or be parameters. This |
178 |
slightly complicates the interface, but allows one OS (for example |
179 |
"debootstrap" to be customizable and not require copies to perform different |
180 |
cations). |
181 |
|
182 |
Each OS will be able to declare which parameters it supports by listing them |
183 |
one per line in a special "parameters" file in the OS dir. The parameters can |
184 |
have a per-os cluster default, or be specified at instance creation time. They |
185 |
will then be passed to the OS scripts as: INSTANCE_OS_PARAMETER_<NAME> with |
186 |
their specified value. The only value checking that will be performed is that |
187 |
the os parameter value is a string, with only "normal" characters in it. |
188 |
|
189 |
It will be impossible to change parameters for an instance, except at reinstall |
190 |
time. Upon reinstall with a different OS the parameters will be by default |
191 |
discarded and reset to the default (or passed) values, unless a special |
192 |
--keep-known-os-parameters flag is passed. |
193 |
|