upgrade-0.16.rst 8.8 KB
Newer Older
1
2
3
Upgrade to Synnefo v0.16
^^^^^^^^^^^^^^^^^^^^^^^^

4
5
6
7
8
9
10
11
12
Introduction
============

Starting with version 0.16, we introduce Archipelago as the new storage backend
for the Pithos Service. Archipelago will act as a storage abstraction layer
between Pithos and NFS, RADOS or any other storage backend driver that Archipelago
supports. In order to use the Pithos Service you must install Archipelago on the
node that runs the Pithos workers.

13
14
15
16
17
18
19
20
21
22

Upgrade Steps
=============

The upgrade to v0.16 consists in the following steps:

1. Bring down services and backup databases.

2. Upgrade packages, migrate the databases and configure settings.

23
3. Inspect and adjust resource limits.
24

25
26
27
4. Tweak Archipelago and Gunicorn settings on Pithos node

5. Bring up all services.
28

29
30
31
6. Add unique names to disks of all Ganeti instances


32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
.. warning::

    It is strongly suggested that you keep separate database backups
    for each service after the completion of each step.

1. Bring web services down, backup databases
============================================

1. All web services must be brought down so that the database maintains a
   predictable and consistent state during the migration process::

    $ service gunicorn stop
    $ service snf-dispatcher stop
    $ service snf-ganeti-eventd stop

2. Backup databases for recovery to a pre-migration state.

3. Keep the database servers running during the migration process.


2. Upgrade Synnefo and configure settings
=========================================

2.1 Install the new versions of packages
----------------------------------------

::

    astakos.host$ apt-get install \
                            python-objpool \
                            snf-common \
                            python-astakosclient \
                            snf-django-lib \
                            snf-webproject \
                            snf-branding \
                            snf-astakos-app

    cyclades.host$ apt-get install \
                            python-objpool \
                            snf-common \
                            python-astakosclient \
                            snf-django-lib \
                            snf-webproject \
                            snf-branding \
                            snf-pithos-backend \
                            snf-cyclades-app

    pithos.host$ apt-get install \
                            python-objpool \
                            snf-common \
                            python-astakosclient \
                            snf-django-lib \
                            snf-webproject \
                            snf-branding \
                            snf-pithos-backend \
                            snf-pithos-app \
88
89
90
91
92
                            snf-pithos-webclient \
                            libxseg0 \
                            python-xseg \
                            python-archipelago \
                            archipelago
93
94
95
96
97
98

    ganeti.node$ apt-get install \
                            python-objpool \
                            snf-common \
                            snf-cyclades-gtools \
                            snf-pithos-backend \
99
100
                            snf-network \
                            snf-image
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128

.. note::

   Make sure `snf-webproject' has the same version with snf-common

.. note::

    Installing the packages will cause services to start. Make sure you bring
    them down again (at least ``gunicorn``, ``snf-dispatcher``)

2.2 Sync and migrate the database
---------------------------------

.. note::

   If you are asked about stale content types during the migration process,
   answer 'no' and let the migration finish.

::

    astakos-host$ snf-manage syncdb
    astakos-host$ snf-manage migrate

    cyclades-host$ snf-manage syncdb
    cyclades-host$ snf-manage migrate

    pithos-host$ pithos-migrate upgrade head

129
130
3. Inspect and adjust resource limits
=====================================
131

132
133
134
135
136
Synnefo 0.16 brings significant changes at the project mechanism. Projects
are now viewed as a source of finite resources, instead of a means to
accumulate quota. They are the single source of resources, and quota are now
managed at a project/member level.

137
138
System-provided quota are now handled through special purpose
user-specific *system projects*, identified with the same UUID as the user.
139
140
141
These have been created during the database migration process. They are
included in the project listing with::

142
  snf-manage project-list --system-projects
143
144
145
146
147
148

All projects must specify quota limits for all registered resources. Default
values have been set for all resources, listed with::

  astakos-host$ snf-manage resource-list

149
150
151
Column `system_default` (previously known as `default_quota`) provides the
skeleton for the quota limits of user-specific system projects. Column
`project_default` is new and acts as skeleton for `applied` (non-system)
152
projects (i.e., for resources not specified in a project application).
153
154
Project defaults have been initialized during migration based on the system
default values: they have been set to `inf` if `system_default` is also `inf`,
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
otherwise set to zero.

This default, affecting all future projects, can be modified with::

  astakos-host$ snf-manage resource-modify <name> --project-default <value>

Till now a project definition contained one quota limit per resource: the
maximum that a member can get from the project. A new limit is introduced:
the grand maximum a project can provide to its members. This new project
limit is initialized during migration as `max members * member limit` (if
`max members` is not set, the double of current active members is assumed).

Existing projects can now be modified directly through the command line. In
order to change a project's resource limits, run::

  astakos-host$ snf-manage project-modify <project_uuid> --limit <resource_name> <member_limit> <project_limit>

With the new mechanism, when a new resource is allocated (e.g., a VM or a
Pithos container is created), it is also associated with a project besides
its owner. The migration process has associated existing resources with
175
176
their owner's system project. Note that users who had made use of projects to
increase their quota may end up overlimit on some resources of their system
177
178
projects and will need to *reassign* some of their reserved resources to
another project in order to overcome this restriction.
179

180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219

4. Tweak Archipelago and Gunicorn settings on Pithos node
=========================================================

After installing Archipelago on Pithos node we need to adjust the configuration
files according to our deployment needs.

For Archipelago the configuration file is located on
``/etc/archipelago/archipelago.conf``, where we need to adjust carefully at
least six configuration options:

* ``BLKTAP_ENABLED``: Must be set to false for the Pithos node, if the node does
  not host VMs (a.k.a is not VM_CAPABLE)
* ``USER``: The user that Archipelago will run as must be the same as the
  Gunicorn user.
* ``GROUP``: The group that Archipelago will run as must be the same as the
  Gunicorn group.
* ``SEGMENT_SIZE``: Adjust shared memory segment size according to your machine's
  RAM. The default value is 2GB which in some situations might exceed your
  machine's physical RAM.
* ``archip_dir`` in ``blockerm`` section must be set to the directory that
  Pithos mapfiles reside until now (e.g., ``/srv/pithos/data/maps``).
  For RADOS installations the ``pool`` setting must be set to the RADOS pool
  that Pithos mapfiles reside.
* ``archip_dir`` in ``blockerb`` section must be set to the directory that
  Pithos data blocks reside until now (e.g., ``/srv/pithos/data/blocks``).
  For RADOS installations the ``pool`` setting must be set to the RADOS pool
  that Pithos data blocks reside.

For Gunicorn the configuration file is located on ``/etc/gunicorn.d/synnefo``
where we need to change:

* ``--worker-class=gevent`` to ``--worker-class=pithos.workers.gevent_archipelago.GeventArchipelagoWorker``

and set:

* ``--config=/etc/synnefo/pithos.conf.py``


5. Bring all services up
220
221
222
223
224
225
226
227
========================

After the upgrade is finished, we bring up all services:

.. code-block:: console

    astakos.host  # service gunicorn start
    cyclades.host # service gunicorn start
228
229

    pithos.host   # service archipelago start
230
231
232
    pithos.host   # service gunicorn start

    cyclades.host # service snf-dispatcher start
233
234
235
236
237
238
239
240
241
242
243
244
245
246


6. Add unique names to disks of all Ganeti instances
=====================================================

Synnefo 0.16 introduces the Volume service which can handle multiple disks
per Ganeti instance. Synnefo assigns a unique name to each Ganeti disk and
refers to it by that unique name. After upgrading to v0.16, Synnefo must
assign names to all existing disks. This can be easily performed with a helper
script that is shipped with version 0.16:

.. code-block:: console

 cyclades.host$ /usr/lib/synnefo/tools/add_unique_name_to_disks