root / docs / upgrade / upgrade-0.15.rst @ 0af59ea1
History | View | Annotate | Download (16.9 kB)
1 |
Upgrade to Synnefo v0.15 |
---|---|
2 |
^^^^^^^^^^^^^^^^^^^^^^^^ |
3 |
|
4 |
Prerequisites |
5 |
============== |
6 |
|
7 |
Before upgrading to v0.15 there are two steps that must be performed, relative |
8 |
with Cyclades networking service. |
9 |
|
10 |
Add unique name to the NICs of all Ganeti instances |
11 |
--------------------------------------------------- |
12 |
|
13 |
Since Ganeti 2.8, it is supported to give a name to NICs of Ganeti instances |
14 |
and refer to them with their name, and not only by their index. Synnefo v0.15 |
15 |
assigns a unique name to each NIC and refers to them by their unique name. |
16 |
Before upgrading to v0.15, Synnefo must assign names to all existing NICs. |
17 |
This can easily be performed with a helper script that is shipped with Synnefo |
18 |
v0.14.10: |
19 |
|
20 |
.. code-block:: console |
21 |
|
22 |
cyclades.host$ /usr/lib/synnefo/tools/add_unique_name_to_nics |
23 |
|
24 |
.. note:: If you are not upgrading from v0.14.10, you can find the migration |
25 |
script :ref:`here <add_names>`. |
26 |
|
27 |
|
28 |
Extend public networks to all Ganeti backends |
29 |
--------------------------------------------- |
30 |
|
31 |
Before v0.15, each public network of Cyclades existed in one of the Ganeti |
32 |
backends. In order to support dynamic addition and removal of public IPv4 |
33 |
address across VMs, each public network must exist in all Ganeti backends. |
34 |
|
35 |
If you are using more than one Ganeti backends, before upgrading to v0.15 you |
36 |
must ensure that the network configuration to all Ganeti backends is identical |
37 |
and appropriate to support all public networks of Cyclades. |
38 |
|
39 |
|
40 |
Upgrade Steps |
41 |
============= |
42 |
|
43 |
The upgrade to v0.15 consists in the following steps: |
44 |
|
45 |
1. Bring down services and backup databases. |
46 |
|
47 |
2. Upgrade packages, migrate the databases and configure settings. |
48 |
|
49 |
3. Create floating IP pools |
50 |
|
51 |
4. Register services and resources. |
52 |
|
53 |
5. Bring up all services. |
54 |
|
55 |
.. warning:: |
56 |
|
57 |
It is strongly suggested that you keep separate database backups |
58 |
for each service after the completion of each step. |
59 |
|
60 |
1. Bring web services down, backup databases |
61 |
============================================ |
62 |
|
63 |
1. All web services must be brought down so that the database maintains a |
64 |
predictable and consistent state during the migration process:: |
65 |
|
66 |
$ service gunicorn stop |
67 |
$ service snf-dispatcher stop |
68 |
$ service snf-ganeti-eventd stop |
69 |
|
70 |
2. Backup databases for recovery to a pre-migration state. |
71 |
|
72 |
3. Keep the database servers running during the migration process. |
73 |
|
74 |
|
75 |
2. Upgrade Synnefo and configure settings |
76 |
========================================= |
77 |
|
78 |
2.1 Install the new versions of packages |
79 |
---------------------------------------- |
80 |
|
81 |
:: |
82 |
|
83 |
astakos.host$ apt-get install \ |
84 |
python-objpool \ |
85 |
snf-common \ |
86 |
python-astakosclient \ |
87 |
snf-django-lib \ |
88 |
snf-webproject \ |
89 |
snf-branding \ |
90 |
snf-astakos-app |
91 |
|
92 |
cyclades.host$ apt-get install \ |
93 |
python-objpool \ |
94 |
snf-common \ |
95 |
python-astakosclient \ |
96 |
snf-django-lib \ |
97 |
snf-webproject \ |
98 |
snf-branding \ |
99 |
snf-pithos-backend \ |
100 |
snf-cyclades-app |
101 |
|
102 |
pithos.host$ apt-get install \ |
103 |
python-objpool \ |
104 |
snf-common \ |
105 |
python-astakosclient \ |
106 |
snf-django-lib \ |
107 |
snf-webproject \ |
108 |
snf-branding \ |
109 |
snf-pithos-backend \ |
110 |
snf-pithos-app \ |
111 |
snf-pithos-webclient |
112 |
|
113 |
ganeti.node$ apt-get install \ |
114 |
python-objpool \ |
115 |
snf-common \ |
116 |
snf-cyclades-gtools \ |
117 |
snf-pithos-backend \ |
118 |
snf-network |
119 |
|
120 |
.. note:: |
121 |
|
122 |
Make sure `snf-webproject' has the same version with snf-common |
123 |
|
124 |
.. note:: |
125 |
|
126 |
Installing the packages will cause services to start. Make sure you bring |
127 |
them down again (at least ``gunicorn``, ``snf-dispatcher``) |
128 |
|
129 |
2.2 Sync and migrate the database |
130 |
--------------------------------- |
131 |
|
132 |
.. note:: |
133 |
|
134 |
If you are asked about stale content types during the migration process, |
135 |
answer 'no' and let the migration finish. |
136 |
|
137 |
:: |
138 |
|
139 |
astakos-host$ snf-manage syncdb |
140 |
astakos-host$ snf-manage migrate |
141 |
|
142 |
cyclades-host$ snf-manage syncdb |
143 |
cyclades-host$ snf-manage migrate |
144 |
|
145 |
pithos-host$ pithos-migrate upgrade head |
146 |
|
147 |
.. _pithos_view_registration: |
148 |
|
149 |
2.3 Register pithos view as an oauth 2.0 client in astakos |
150 |
---------------------------------------------------------- |
151 |
|
152 |
Starting from synnefo version 0.15, the pithos view, in order to get access to |
153 |
the data of a protect pithos resource, has to be granted authorization for the |
154 |
specific resource by astakos. |
155 |
|
156 |
During the authorization grant procedure, it has to authenticate itself with |
157 |
astakos since the later has to prevent serving requests by unknown/unauthorized |
158 |
clients. |
159 |
|
160 |
To register the pithos view as an OAuth 2.0 client in astakos, use the |
161 |
following command:: |
162 |
|
163 |
snf-manage oauth2-client-add pithos-view --secret=<secret> --is-trusted --url https://pithos.synnefo.live/pithos/ui/view |
164 |
|
165 |
2.4 Update configuration files |
166 |
------------------------------ |
167 |
|
168 |
The ``ASTAKOS_BASE_URL`` setting has been replaced (both in Cyclades and |
169 |
Pithos services) with the ``ASTAKOS_AUTH_URL`` setting. |
170 |
|
171 |
For Cyclades service we have to change the ``20-snf-cyclades-app-api.conf`` |
172 |
file, remove the ``ASTAKOS_BASE_URL`` setting and replace it with |
173 |
``ASTAKOS_AUTH_URL``. Typically it is sufficient to add ``/identity/v2.0`` |
174 |
at the end of base url to get the auth url. For example if base url had the |
175 |
value of 'https://accounts.example.synnefo.org/' then the ``ASTAKOS_AUTH_URL`` |
176 |
setting will have the value of |
177 |
'https://accounts.example.synnefo.org/identity/v2.0'. |
178 |
|
179 |
For Pithos service we have to change the ``20-snf-pithos-app-settings.conf`` |
180 |
file in the same way as above. In addition to this, we have to change the |
181 |
``PITHOS_OAUTH2_CLIENT_CREDENTIALS`` setting in the same configuration file |
182 |
to set the credentials issued for the pithos view in `the previous step`__. |
183 |
|
184 |
__ pithos_view_registration_ |
185 |
|
186 |
|
187 |
2.5 Upgrade vncauthproxy and configure snf-cyclades-app |
188 |
------------------------------------------------------- |
189 |
|
190 |
Synnefo v0.15 adds support for snf-vncauthproxy >= 1.5 and drops support for |
191 |
older versions. You will have to upgrade snf-vncauthproxy to v1.5 and |
192 |
configure the authentication (users) file (``/var/lib/vncauthproxy/users``). |
193 |
|
194 |
In case you're upgrading from an older snf-vncauthproxy version or if it's the |
195 |
first time you're installing snf-vncauthproxy, you will need to add a |
196 |
vncauthproxy user (see below for more information on user management) and |
197 |
restart vncauthproxy daemon. |
198 |
|
199 |
To manage the authentication file, you can use the vncauthproxy-passwd tool, |
200 |
to easily add, update and delete users. |
201 |
|
202 |
To add a user: |
203 |
|
204 |
.. code-block:: console |
205 |
|
206 |
# vncauthproxy-passwd /var/lib/vncauthproxy/users synnefo |
207 |
|
208 |
You will be prompted for a password. |
209 |
|
210 |
You should also configure the new ``CYCLADES_VNCAUTHPROXY_OPTS`` setting in |
211 |
``snf-cyclades-app``, to provide the user and password configured for |
212 |
``Synnefo`` in the vncauthproxy authentication file and enable SSL support if |
213 |
snf-vncauthproxy is configured to run with SSL enabled for the control socket. |
214 |
|
215 |
.. warning:: The vncauthproxy daemon requires a restart for the changes in the |
216 |
authentication file to take effect. |
217 |
|
218 |
.. warning:: If you fail to provide snf-vncauthproxy with a valid |
219 |
authentication file, or in case the configuration of vncauthproxy and the |
220 |
vncauthproxy snf-cyclades-app settings don't match (ie not having SSL enabled |
221 |
on both), VNC console access will not be functional. |
222 |
|
223 |
Finally, snf-vncauthproxy-1.5 adds a dedicated user and group to be used by the |
224 |
vncauthproxy daemon. The Debian default file has changed accordingly (``CHUID`` |
225 |
option in ``/etc/default/vncauthproxy``). The Debian default file now also |
226 |
includes a ``DAEMON_OPTS`` variable which is used to pass any necessary / extra |
227 |
options to the vncauthproxy daemon. In case you're ugprading from an older |
228 |
version of vncauthproxy, you should make sure to 'merge' the new default file |
229 |
with the older one. |
230 |
|
231 |
Check the `documentation |
232 |
<http://www.synnefo.org/docs/snf-vncauthproxy/latest/index.html>`_ of |
233 |
snf-vncauthproxy for more information on upgrading to version 1.5. |
234 |
|
235 |
2.6 Stats configuration |
236 |
----------------------- |
237 |
|
238 |
snf-cyclades-gtools comes with a collectd plugin to collect CPU and network |
239 |
stats for Ganeti VMs and an example collectd configuration. snf-stats-app is a |
240 |
Django (snf-webproject) app that serves the VM stats graphsmm by reading the VM |
241 |
stats (from RRD files) and serves graphs. |
242 |
|
243 |
To enable / deploy VM stats collecting and snf-stats-app see the relevant |
244 |
documentation in the :ref:`admin guide <admin-guide-stats>`. |
245 |
|
246 |
If you were using collectd to collect VM stats on Debian squeeze and you are |
247 |
upgrading to Wheezy, you will need to upgrade your RRD files. Follow the |
248 |
instructions on the collectd v4-to-v5 migration `guide |
249 |
<https://collectd.org/wiki/index.php/V4_to_v5_migration_guide>`_. |
250 |
You will proabably just need to run the `migration script |
251 |
<https://collectd.org/wiki/index.php/V4_to_v5_migration_guide#Migration_script>`_ |
252 |
provided. |
253 |
|
254 |
If you were using a previous version of snf-stats-app, you should also make |
255 |
sure to set the ``STATS_BASE_URL`` setting in ``20-snf-stats-app-settings.conf`` |
256 |
to match your deployment and change the graph URL settings in |
257 |
``20-snf-cyclades-app-api.conf`` accordingly. |
258 |
|
259 |
v0.15 has also introduced the ``CYCLADES_STATS_SECRET_KEY`` and |
260 |
``STATS_SECRET_KEY`` settings. ``CYCLADES_STATS_SECRET_KEY`` in |
261 |
``20-snf-cyclades-app-api.conf`` is used by Cyclades to encrypt the instance id |
262 |
/ hostname in the URLs serving the VM stats. You should set it to a random |
263 |
value / string and make sure that it's the same as the ``STATS_SECRET_KEY`` |
264 |
setting (used to decrypt the instance hostname) in |
265 |
``20-snf-stats-settings.conf`` on your Stats host. |
266 |
|
267 |
2.7 Shibboleth configuration updates |
268 |
------------------------------------ |
269 |
|
270 |
.. note:: |
271 |
|
272 |
Skip this step unless you have ``shibboleth`` enabled in astakos |
273 |
``IM_MODULES`` setting. |
274 |
|
275 |
As of v0.15 astakos uses the ``REMOTE_USER`` header provided by apache's |
276 |
``mod_shib2`` service in order to resolve the unique identifier which is used to |
277 |
associate a shibboleth account to a local astakos user. Prior to this version |
278 |
astakos adhered to the presence of the ``MOD_SHIB_EPPN`` header which although |
279 |
safe enough on most of the ``SP`` deployment scenarios, it may cause issues in |
280 |
certain cases, such as global wide IdP support or inability of supported IdPs |
281 |
to release the ``eduPersonPrincipalName`` attribute. The ``REMOTE_USER`` header |
282 |
can be set by administrators to match any of the available shibboleth |
283 |
attributes. |
284 |
|
285 |
If ``EPPN`` matches the service provider needs and you want to continue using |
286 |
it as the unique identifier, you need to ensure that the ``REMOTE_USER`` |
287 |
attribute is set to ``eppn`` in the ``mod_shib2`` config file located at |
288 |
``/etc/shibboleth/shibboleth2.xml`` |
289 |
|
290 |
.. code-block:: xml |
291 |
|
292 |
<!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. --> |
293 |
<ApplicationDefaults entityID="https://sp.example.org/shibboleth" REMOTE_USER="eppn"> |
294 |
|
295 |
Otherwise, if ``EPPN`` doesn't suit the requirements for your ``SP`` |
296 |
deployment, change the ``REMOTE_USER`` attribute as required e.g.: |
297 |
|
298 |
.. code-block:: xml |
299 |
|
300 |
<!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. --> |
301 |
<ApplicationDefaults entityID="https://sp.example.org/shibboleth" REMOTE_USER="persistent-nameid persistent-id targeted-id"> |
302 |
|
303 |
and restart the ``shibd`` service: |
304 |
|
305 |
.. code-block:: console |
306 |
|
307 |
$ service shibd restart |
308 |
|
309 |
**notice** that every time you alter the ``REMOTE_USER`` attribute, all |
310 |
existing shibboleth enabled astakos users will be invalidated and no longer be |
311 |
able to login to their existing account using shibboleth. Specifically for the |
312 |
case of switching from *eppn* to another attribute, astakos is able to prevent |
313 |
invalidation and automatically migrate existing *eppn* accounts. In order to do |
314 |
that, set the ``ASTAKOS_SHIBBOLETH_MIGRATE_EPPN`` setting to ``True`` in |
315 |
``20-snf-astakos-app-settings.conf`` configuration file. Now every time an |
316 |
existing *eppn* user logs in using shibboleth, astakos will update the associated |
317 |
*eppn* identifier to the contents of the ``REMOTE_USER`` header. |
318 |
|
319 |
.. warning:: |
320 |
|
321 |
IdPs should keep releasing the ``EPPN`` attribute in order for the migration |
322 |
to work. |
323 |
|
324 |
3. Create floating IP pools |
325 |
=========================== |
326 |
|
327 |
Synnefo v0.15 introduces floating IPs, which are public IPv4 addresses that can |
328 |
dynamically be added/removed to/from VMs and are quotable via the |
329 |
'cyclades.floating_ip' resource. Connecting a VM to a public network is only |
330 |
allowed if the user has firstly created a floating IP from this network. |
331 |
|
332 |
Floating IPs are created from networks that are marked as Floating IP pools. |
333 |
Creation of floating IP pools is done with the `snf-manage network-create` |
334 |
command using the `--floating-ip-pool` option. |
335 |
|
336 |
Existing networks can be converted to floating IPs using `network-modify` |
337 |
command: |
338 |
|
339 |
.. code-block:: console |
340 |
|
341 |
snf-manage network-modify --floating-ip-pool=True <network_ID> |
342 |
|
343 |
Already allocated public IPv4 addresses are not automatically converted to |
344 |
floating IPs. Existing VMs can keep their IPv4 addresses which will be |
345 |
automatically be released when these VMs will be destroyed. In order to |
346 |
convert existing public IPs to floating IPs run the following command: |
347 |
|
348 |
.. code-block:: console |
349 |
|
350 |
cyclades.host$ /usr/lib/synnefo/tools/update_to_floating_ips |
351 |
|
352 |
or for just one network: |
353 |
|
354 |
.. code-block:: console |
355 |
|
356 |
cyclades.host$ /usr/lib/synnefo/tools/update_to_floating_ips --network-id=<network_ID> |
357 |
|
358 |
4. Register services and resources |
359 |
================================== |
360 |
|
361 |
4.1 Re-register service and resource definitions |
362 |
------------------------------------------------ |
363 |
|
364 |
You will need to register again all Synnefo components, updating the |
365 |
service and resource definitions. On the astakos node, run:: |
366 |
|
367 |
astakos-host$ snf-component-register |
368 |
|
369 |
This will detect that the Synnefo components are already registered and ask |
370 |
to re-register. Answer positively. You need to enter the base URL and the UI |
371 |
URL for each component, just like during the initial registration. |
372 |
|
373 |
.. note:: |
374 |
|
375 |
You can run ``snf-manage component-list -o name,ui_url`` to inspect the |
376 |
current registered UI URL. In the default installation, the base URL can |
377 |
be found by stripping ``/ui`` from the UI URL. |
378 |
|
379 |
The meaning of resources ``cyclades.cpu`` and ``cyclades.ram`` has changed: |
380 |
they now denote the number of CPUs and, respectively, RAM of *active* VMs |
381 |
rather than all VMs. To represent total CPUs and total RAM, as previously, |
382 |
new resources ``cyclades.total_cpu`` and ``cyclades.total_ram`` are |
383 |
introduced. We now also control the usage of floating IPs through resource |
384 |
``cyclades.floating_ip``. |
385 |
|
386 |
4.2 Tweek resource settings |
387 |
--------------------------- |
388 |
|
389 |
New resources (``cyclades.total_cpu``, ``cyclades.total_ram``, and |
390 |
``cyclades.floating_ip``) are registered with infinite default base quota. |
391 |
You will probably need to restrict them, especially |
392 |
``cyclades.floating_ip``. In order to change the default for all *future* |
393 |
users, for instance restricting floating IPs to 2, run:: |
394 |
|
395 |
astakos-host$ snf-manage resource-modify cyclades.floating_ip --default-quota 2 |
396 |
|
397 |
Note that this command does not affect *existing* users any more. They can |
398 |
still have infinite floating IPs. You can update base quota of existing |
399 |
users in bulk, possibly excluding some users, with:: |
400 |
|
401 |
astakos-host$ snf-manage user-modify --all --base-quota cyclades.floating_ip 2 --exclude uuid1,uuid2 |
402 |
|
403 |
.. note:: |
404 |
|
405 |
You can inspect base quota with ``snf-manage quota-list`` before applying |
406 |
any changes, for example:: |
407 |
|
408 |
# Get users with cyclades.vm base quota that differ from the default value |
409 |
astakos-host$ snf-manage quota-list --with-custom=True --filter-by "resource=cyclades.vm" |
410 |
|
411 |
# Get users with cyclades.vm base quota greater than 3 |
412 |
astakos-host$ snf-manage quota-list --filter-by "resource=cyclades.vm,base_quota>3" |
413 |
|
414 |
It is now possible to control whether a resource is visible for the users |
415 |
through the API or the UI. Note that the system always checks resource |
416 |
quota, regardless of their visibility. By default, ``cyclades.total_cpu``, |
417 |
``cyclades.total_ram`` and ``astakos.pending_app`` are not visible. You can |
418 |
change this behavior with:: |
419 |
|
420 |
astakos-host$ snf-manage resource-modify <resource> --api-visible=True (or --ui-visible=True) |
421 |
|
422 |
4.3 Update the Quotaholder |
423 |
-------------------------- |
424 |
|
425 |
To update quota for all new or modified Cyclades resources, bring up Astakos:: |
426 |
|
427 |
astakos-host$ service gunicorn start |
428 |
|
429 |
and run on the Cyclades node:: |
430 |
|
431 |
cyclades-host$ snf-manage reconcile-resources-cyclades --fix --force |
432 |
|
433 |
|
434 |
5. Bring all services up |
435 |
======================== |
436 |
|
437 |
After the upgrade is finished, we bring up all services: |
438 |
|
439 |
.. code-block:: console |
440 |
|
441 |
astakos.host # service gunicorn start |
442 |
cyclades.host # service gunicorn start |
443 |
pithos.host # service gunicorn start |
444 |
|
445 |
cyclades.host # service snf-dispatcher start |