root / docs / admin.rst @ 4a3e83c6
History | View | Annotate | Download (3.3 kB)
1 |
README.admin - Administration notes |
---|---|
2 |
|
3 |
This file contains notes related to administration of a working Synnefo |
4 |
deployment. This document should be read *after* README.deploy, which contains |
5 |
step-by-step Synnefo deployment instructions. |
6 |
|
7 |
|
8 |
Database |
9 |
======== |
10 |
|
11 |
MySQL: manage.py dbshell seems to ignore the setting of 'init_command' |
12 |
in settings.DATABASES |
13 |
|
14 |
|
15 |
Reconciliation mechanism |
16 |
======================== |
17 |
|
18 |
On certain occasions, such as a Ganeti or RabbitMQ failure, the VM state in the |
19 |
system's database may differ from that in the Ganeti installation. The |
20 |
reconciliation process is designed to bring the system's database in sync with |
21 |
what Ganeti knows about each VM, and is able to detect the following three |
22 |
conditions: |
23 |
|
24 |
* Stale DB servers without corresponding Ganeti instances |
25 |
* Orphan Ganeti instances, without corresponding DB entries |
26 |
* Out-of-sync operstate for DB entries wrt to Ganeti instances |
27 |
|
28 |
The reconciliation mechanism runs as a management command, e.g., as follows: |
29 |
[PYTHONPATH needs to contain the parent of the synnefo Django project |
30 |
directory]: |
31 |
|
32 |
/srv/synnefo$ export PYTHONPATH=/srv:$PYTHONPATH |
33 |
vkoukis@dev67:~/synnefo [reconc]$ ./manage.py reconcile --detect-all -v 2 |
34 |
|
35 |
Please see ./manage.py reconcile --help for all the details. |
36 |
|
37 |
The administrator can also trigger reconciliation of operating state manually, |
38 |
by issuing a Ganeti OP_INSTANCE_QUERY_DATA command on a Synnefo VM, using |
39 |
gnt-instance info. |
40 |
|
41 |
|
42 |
Logging |
43 |
======= |
44 |
|
45 |
Logging in Synnefo is using Python's logging module. The module is configured |
46 |
using dictionary configuration, whose format is described here: |
47 |
|
48 |
http://docs.python.org/release/2.7.1/library/logging.html#logging-config-dictschema |
49 |
|
50 |
Note that this is a feature of Python 2.7 that we have backported for use in |
51 |
Python 2.6. |
52 |
|
53 |
The logging configuration dictionary is defined in settings.d/00-logging.conf |
54 |
and is broken in 4 separate dictionaries: |
55 |
|
56 |
* LOGGING is the logging configuration used by the web app. By default all |
57 |
loggers fall back to the main 'synnefo' logger. The subloggers can be |
58 |
changed accordingly for finer logging control. e.g. To disable debug |
59 |
messages from the API set the level of 'synnefo.api' to 'INFO'. |
60 |
|
61 |
* DISPATCHER_LOGGING is the logging configuration of the logic/dispatcher.py |
62 |
command line tool. |
63 |
|
64 |
* SNFADMIN_LOGGING is the logging configuration of the snf-admin tool. |
65 |
Consider using matching configuration for snf-admin and the synnefo.admin |
66 |
logger of the web app. |
67 |
|
68 |
Please note the following: |
69 |
* As of Synnefo v0.7, by default the Django webapp logs to syslog, the |
70 |
dispatcher logs to /var/log/synnefo/dispatcher.log and the console, |
71 |
snf-admin logs to the console. |
72 |
* Different handlers can be set to different logging levels: |
73 |
for example, everything may appear to the console, but only INFO and higher |
74 |
may actually be stored in a longer-term logfile. |
75 |
|
76 |
|
77 |
Admin Tools |
78 |
=========== |
79 |
|
80 |
snf-admin is a tool used to perform various administrative tasks. It needs to |
81 |
be able to access the django database, so the following should be able to import |
82 |
the Django settings. |
83 |
|
84 |
Additionally, administrative tasks can be performed via the admin web interface |
85 |
located in /admin. Only users of type ADMIN can access the admin pages. To change |
86 |
the type of a user to ADMIN, snf-admin can be used: |
87 |
|
88 |
snf-admin user modify 42 --type ADMIN |