Module masterd
source code
Master daemon program.
Some classes deviates from the standard style guide since the
inheritance from parent classes requires it.
|
|
|
|
|
|
|
|
|
|
|
CheckMasterd(options,
args)
Initial checks whether to run or exit with a failure. |
source code
|
|
|
|
PrepMasterd(options,
_)
Prep master daemon function, executed with the PID file held. |
source code
|
|
|
|
ExecMasterd(options,
args,
prep_data)
Main master daemon function, executed with the PID file held. |
source code
|
|
|
|
|
|
|
CLIENT_REQUEST_WORKERS = 16
|
|
|
EXIT_NOTMASTER = 11
|
|
|
EXIT_NODESETUP_ERROR = 12
|
Imports:
grp,
os,
pwd,
sys,
socket,
time,
tempfile,
logging,
OptionParser,
config,
constants,
daemon,
mcpu,
opcodes,
jqueue,
locking,
luxi,
utils,
errors,
ssconf,
workerpool,
rpc,
bootstrap,
netutils
|
Creates or removes the watcher pause file.
- Parameters:
until (None or int) - Unix timestamp saying until when the watcher shouldn't run
|
|
Check the agreement on who is the master.
The function uses a very simple algorithm: we must get more positive
than negative answers. Since in most of the cases we are the master,
we'll use our own config file for getting the node list. In the future we
could collect the current node list from our (possibly obsolete) known
nodes.
In order to account for cold-start of all nodes, we retry for up to a
minute until we get a real answer as the top-voted one. If the nodes are
more out-of-sync, for now manual startup of the master should be
attempted.
Note that for a even number of nodes cluster, we need at least half of
the nodes (beside ourselves) to vote for us. This creates a problem on
two-node clusters, since in this case we require the other node to be up
too to confirm our status.
- Decorators:
|