glusterfs.git/xlators/features/marker/utils/syncdaemon/syncdutils.py, branch v3.4.4beta1

geo-rep: do not access BaseException.message in syncdutils

2012-12-18T22:17:35+00:00

http://www.python.org/dev/peps/pep-0352/ explains that the .message
property of BaseException is being removed. Most of the other exception
handlers access .args[] which should be suitable for this
case too.

Change-Id: I1810450b78d2b3d7f8bd07f2beb02cbe9e2adecb
BUG: 888346
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/4328
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

geo-rep: checkpointing

2012-06-13T15:37:41+00:00

- gluster vol geo-rep M S conf checkpoint 

  sets a checkpoint with LABEL (the keyword "now" is special,
  it's rendered to the label "as of ")
  that's used to refer to the checkpoint in the sequel.

  (Technically, gsyncd makes a note of the xtime of master's root
  as of setting the checkpoint, called the "checkpoint target".)

- gluster vol geo-rep M S conf \!checkpoint

  deletes the checkpoint.

- gluster vol geo-rep M S stat

  if status is OK, and there is a checkpoint configured, the checkpoint
  info is appended to status (either "not yet reached", or
  "completed at ").

  (Technically, the worker runs a thread that monitors / serializes /
  verifies checkpoint status, and answers checkpoint status requests
  through a UNIX socket; monitoring boils down to querying the xtime
  of slave's root and comparing with the target.)

- gluster vol geo-rep M S conf log-file | xargs grep checkpoint

  displays the checkpoint history. Set, delete and completion events
  are logged properly.

Change-Id: I4398e0819f1504e6e496b4209e91a0e156e1a0f8
BUG: 826512
Signed-off-by: Csaba Henk 
Reviewed-on: http://review.gluster.com/3491
Tested-by: Gluster Build System 
Reviewed-by: Venky Shankar

geo-rep / gsyncd: further cleanup refinements

2012-05-25T01:22:52+00:00

- Regarding issue of leftover ssh control dirs:

  If master side worker is stuck in connection establishment
  phase, have the monitor kill it softly (ie. first by SIGTERM,
  to let it cleanup). This is trickier than sounds on first hearing,
  because if worker is stuck in waiting for a RePCe answer
  (in threading.Condition().wait()), then SIGTERM is ignored
  (more precisely, Python holds it back for the wait and resends it to
  itself when wait is over).

  So instead of signalling the worker only, we send TERM to the
  whole process group -- that brings down the ssh connection, which
  wakes up the waiting worker, which then can cleanup. Only problem
  is that monitor is also in the process group and it should not coomit
  a suicide. That is taken care by setting up a one-time SIGTERM
  handler in the monitor.

- Regarding slave gsyncd stuck in chdir:

  Slave gsyncd is usually well behaved: if master does not send
  keepalives, it takes care to exit. However, if a hang occurs
  in early phase, when slave is to change to the gluster mountpoint,
  no timeout is set up for that (and unlike on master side, neither
  is there an external actor like the monitor to do that).

  So, to manage this scenario, we do the chdir in a (supposedly)
  short lived thread, and in the main thread we wait for the termination
  of this thread. If that does not happen within the time limit, main
  thread calls for cleanup and exit. (This logic explicitely takes the
  appropriate action in the cases when chdir succeeds or when hangs;
  but what about the remaining case, when chdir fails? Well in that case
  the chdir thread's exception handler will put the process to
  cleanup and exit route.)

Change-Id: I6ad6faa9c7b1c37084d171d1e1a756abaff9eba8
BUG: 786291
Signed-off-by: Csaba Henk 
Reviewed-on: http://review.gluster.com/3376
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

geo-rep / gsyncd: fixes regarding the command invocation framework

2012-05-19T13:11:45+00:00

Some of the bugs to fix were found by the following stress-test:
make "glusterfs --client-pid=-1" exit immediately on slave
side.

Also fix eintr_wrap which should not "adopt" exceptions generated
by the wrapped call, by re-raising them as GsyncdError.

Change-Id: Ia0d39e0635975ebbbf98d86e1e26f3122e1ed6ff
BUG: 764678
Signed-off-by: Csaba Henk 
Reviewed-on: http://review.gluster.com/3258
Tested-by: Gluster Build System 
Reviewed-by: Venky Shankar

geo-rep / gsyncd: recognize ECONNABORTED as termination of aux glusterfs

2012-05-19T12:45:37+00:00

Don't dump stack, rather log the "glusterfs session went down" message.

If the aux glusterfs is already dead when we try to do some file
operation, we get a failure with ENOTCONN, which is already handled
as above. However, it's also possible that glusterfs dies while we
are in a syscall into it -- in that case we get ECONNABORTED, and
so far then we end up with an ugly stack strace. From now on we
take ECONNABORTAD as well into consideration.

Nb. wrt. testing: it's not easy to synthetically force the aux glusterfs
to end this way; for that we have to provoke gsyncd into intensive
synchronization. I succeeded in that with the following ruby oneliner:

ruby -rcgi -e '
  Dir.chdir($*[0])
  a=[]
  Thread.new { loop { while a.size >= 100; File.delete a.shift; end; sleep 1 }}
  loop { a<
Reviewed-on: http://review.gluster.com/3078
Tested-by: Gluster Build System 
Reviewed-by: Venky Shankar 
Reviewed-by: Vijay Bellur

geo-rep / syncdaemon: determine suitable xattr namespace based on privilege

2012-03-05T15:52:54+00:00

Change-Id: I91fe16d7e5e4c21f138eab4ee0b9334aec40e41b
BUG: 765433
Signed-off-by: Csaba Henk 
Reviewed-on: http://review.gluster.com/2838
Tested-by: Gluster Build System 
Reviewed-by: Venky Shankar

geo-rep: gsyncd: Python3 compat fixes

2012-01-26T10:07:15+00:00

Change-Id: I2eef82faab3eed1189e3786a5dca296773e1caa0
BUG: 784498
Signed-off-by: Venky Shankar 
Reviewed-on: http://review.gluster.com/2690
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Csaba Henk

cli: add geo-replication log-rotate command

2011-10-21T06:26:23+00:00

Rotating geo-replication master/monitor log files from cli.
On invocation, the log file for a given master-slave session
is backed up with the current timestamp suffixed to the file
name and signal is sent to gsyncd to start logging to a new
log file.

Sample commands:

* Rotate log file for this : session:
gluster volume geo-replication   log-rotate

* Rotate log files for all session for master volume 
gluster volume geo-replication  log-rotate

* Rotate log files for all sessions:
gluster volume geo-replication log-rotate

Change-Id: I75f641b4e082a04d5373c18583ca4a1d9651d27a
BUG: 3519
Reviewed-on: http://review.gluster.com/529
Tested-by: Gluster Build System 
Reviewed-by: Csaba Henk

geo-rep: gsyncd: add --ignore-deletes option

2011-09-20T17:32:55+00:00

When this option is set, a file deleted on master will not trigger
a delete operation on the slave. Hence, the slave will remain as a
superset of the master and can be used to recover the master in case
of crash and/or accidental deletes.

This options is not enabled by default.

Change-Id: I9244d9dfa4f38f19436036f36bec0d9c3a1f7993
BUG: 3552
Reviewed-on: http://review.gluster.com/426
Tested-by: Gluster Build System 
Reviewed-by: Csaba Henk

geo-rep: partial support for unprivileged gsyncd via mountbroker

2011-09-12T13:24:20+00:00

gsyncd:
  - mounting code is split to a direct and a mountbroker based backend
  - option gluster-command gone
  - new options: gluster-params, gluster-cli-options, mountbroker
  - mountbroker mount backend is used if either a mountbroker label
    is given through the mountbroker option, or if gsyncd is
    unprivileged; in this case the username is used as label
  - have gluster cli invocations log to stderr so that we don't
    hit a permission issue with the logfiles
glusterd:
  - do gsyncd pre-config with new options
  - add option geo-replication-log-group, so if that specified
    geo-rep logfile directories are given to that group (and
    thus members of the given group can do logging there)

This is just WIP as geo-rep relies on trusted extended attributes
and those are not accessible for unprivileged users. Even if we
solved this issue, glusterd security settings are too coarse,
so that if we made it possible for an unprivileged gsyncd
to operate, we would open up too far.

Change-Id: Icd520b58cbadccea3fad7c0f437b99de1e22db14
BUG: 2825
Reviewed-on: http://review.gluster.com/399
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur