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