Statistics
| Branch: | Tag: | Revision:

root / README.admin @ 3a4e3bac

History | View | Annotate | Download (2.8 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
Reconciliation mechanism
9
========================
10

    
11
On certain occasions, such as a Ganeti or RabbitMQ failure, the VM state in the
12
system's database may differ from that in the Ganeti installation. The
13
reconciliation process is designed to bring the system's database in sync with
14
what Ganeti knows about each VM.
15

    
16
The administrator can trigger reconciliation manually, by issuing a Ganeti
17
OP_INSTANCE_QUERY_DATA command, using gnt-instance info.
18

    
19
Alternatively, the reconciliation process can be triggered for all VMs using the
20
command
21

    
22
  ./manage.py reconcile --all
23

    
24
It is advised, though not strictly necessary, to run the reconciliation process
25
periodically, through cron. To avoid overloading the Ganeti master, the periodic
26
reconciliation process takes a staggered approach to updating the VMs, which is
27
configured through the following parameters:
28

    
29
* The settings.py RECONCILIATION_MIN parameter, which specifies the maximum time
30
  a VM can remain ``non-reconciled''. (default: 30 mins)
31

    
32
* The --interval option to the reconcile command, which declares the interval
33
  time between reconciliation attempts (default: 1 min)
34

    
35
On each invocation of the reconcile command, the system will trigger a
36
reconciliation for ((num_all_vms/RECONCILIATION_MIN) * interval) machines.
37
Obviously the lower the interval value and the higher the setting of
38
RECONCILIATION_MIN, the less load is going to be put on Ganeti.
39

    
40
Logging
41
=======
42

    
43
Logging in Synnefo is using Python's logging module. The module is configured
44
using a configuration file, whose format is described here:
45

    
46
http://docs.python.org/library/logging.config.html
47

    
48
By default, the log initialization code will look for the logging.conf file
49
in the following locations in order:
50

    
51
1. /etc/synnefo/logging.conf
52
2. os.getcwd()/logging.conf
53
3. synnefo.logic.__path__[0]/logging.conf (<-- this is the default)
54

    
55
The default configuration is using Linux conventions: it logs to /dev/log for
56
all loggers. The default configuration can be changed by copying the default
57
file to any of the above mentioned locations and changing it appropriately.
58

    
59
* Logging and demonization: If the logging is configured to print to the console
60
  (using the consoleHandler handler) then daemon processes (notably, the
61
  dispatcher) will not work as it should. This only happens after the daemon
62
  has lost its controlling terminal (e.g. because the terminal was closed);
63
  in this case the dispatcher does not know where to log to and depending on
64
  the system it either crashes or stalls. This can be avoided if the logging
65
  module is not configured to output to the console.