glusterfs.git/tests/features/ipc.t, branch v3.12.5

tests: disable IPC test-case

2017-07-18T11:13:34+00:00

The IPC test-case is not correct, and can cause segfaults or hangs. The
ipctest.py script calls glfs_ipc() with the `glfs_t` structure, but
should do so with a `glfs_fd_t`.

In addition, the test-case is written in a way that we do not suggest to
use libgfapi. Python scripts are encouraged to use the bindings from the
libgfapi-python project. It would be better to rewrite the test in C so
that there is type-checking while compiling and no additional issues
with portability (see `LD_PRELOAD` note in the `.t` file).

Change-Id: Icb52b5b1585fbee98f2c694547c31df0aa2ba70b
Updates: #269
Signed-off-by: Niels de Vos 
Reviewed-on: https://review.gluster.org/17786
CentOS-regression: Gluster Build System 
Smoke: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Raghavendra Talur

Tests: portability fixes for ipc.t

2015-03-31T06:45:10+00:00

This fixes portability problems in ipc.t so that it can run on NetBSD:

1) EOPNOTSUPP value is OS-dependent. Learn it from system headers
   instead of hard-coding it in the script

2) liglusterfs embbeds its own UUID implementation. The function name
   may be the same as in built(in implementation from libc, but with
   different prototype. In that case, we must make sure python will
   use libglusterfs's version, otherwise we will crash in libc's UUID
   code. Since dlopen() does not make any guarantee on what symbol
   will be used, me need to preload libglusterfs when loading python.
   This is done using LD_PRELOAD.

3) In python code we need to load with RTLD_GLOBAL global in order
   to have dependencies loaded

4) Python's ctypes.util.find_library does not lookup LD_LIBRARy_PATH
   and may therefore miss the library. On failure, retry with less
   portable but more reliable explicit name

BUG: 1129939
Change-Id: I024cdfd03a5a42a8ec23de38a99e7349aba92ea8
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/9944
Reviewed-by: Kaleb KEITHLEY 
Tested-by: Gluster Build System 
Reviewed-by: Venky Shankar 
Reviewed-by: Vijay Bellur

every/where: add GF_FOP_IPC for inter-translator communication

2015-03-17T14:02:15+00:00

Several features - e.g. encryption, erasure codes, or NSR - involve
multiple cooperating translators which sometimes need a "private" means
of communication amongst themselves.  Historically we've used virtual or
synthetic xattrs, but that's not very elegant and clutters up the
getxattr/setxattr path which must also handle real xattr requests.  This
new fop should address that.

The only argument is an int32_t "op" which should be recognized by the
target translator.  It is recommended that translators using these
feature follow some convention regarding the ops that they define, to
avoid conflicts.  Using a hash of the target translator's type string as
a base for a series of ops would probably be a good start.  Any other
information can be passed in both directions using xdata.

The default behavior for this fop, as with any other, is to pass through
to FIRST_CHILD.  That makes use of this fop "transparent" to other
translators that were written before it existed, but it also means that
it only really works with pass-through translators.  If a routing
translator (such as DHT) or a fan-out translator (such as AFR) is
involved, the IPC might not reach its intended destination unless those
translators are modified to forward IPC fops along all paths.

If an IPC gets all the way to storage/posix it is considered an error,
much like an uncaught exception.  We don't actually *do* anything in
that case, but we do log it send back an EOPNOTSUPP error.  This makes
the "unrecognized opcode" condition distinguishable from the "no IPC
support" condition (which would yield an RPC error instead) so clients
can probe for the presence of a handler for their own favorite opcode
and either use that or use old-school xattrs depending on the result.

BUG: 1158628
Signed-off-by: Venky Shankar 
Signed-off-by: Jeff Darcy 
Change-Id: I84af1b17babe5b30ec03ecf027ae37d09b873968
Reviewed-on: http://review.gluster.org/8812
Reviewed-by: Vijay Bellur