crimson ProtocolV2 class is following a state-machine design style:
* states are defined in ProtocolV2::state_t;
* call `execute_<state_name>()` methods to trigger different states;
* V2 logics are implemented in each execute_<state_name>() methods, and
with explicit transitions to other states at the end of the execute_*;
* each state is associated with a write state defined in Protocol.h:
- none: not allowed to send;
- delay: messages can be queued, but will be delayed to send;
- open: dispatch queued message/keepalive/ack;
- drop: not send any messages, drop them all.
crimson ProtocolV2 is alike async ProtocolV2, with some considerations:
* explicit and encapsulated client/server handshake workflow.
* futurized-exception-based fault handling, which can interrupt protocol
workflow at any time in each state.
* introduced SERVER_WAIT state, meaning to wait for peer-client's socket
to reset or be replaced, and expect no further reads.
* introduced an explicit REPLACING state, async-msgr would be at the
NONE state during replacing.
Signed-off-by: Yingxin Cheng <yingxincheng@gmail.com>
The simplest async-msgr server which will have the same behavior with
crimson-msgr server for apple-to-apple performance test.
Signed-off-by: Yingxin Cheng <yingxincheng@gmail.com>
New features:
* --jobs: start multiple client messengers from core #1 ~ #jobs;
* --core: can assign server core to get away from busy client cores;
* --rounds: a client will send <rounds>/<jobs> messages;
Improved:
* Better configuration report;
* Report individual client results plus a summary;
* Validate if CPU number is sufficient before running;
* Sleep 1 second while connecting, so it won't hurt performance;
* Simplify client logic and bug fixes;
Removed unecessary features:
* finish_decode() for MOSDOp;
* keepalive ratio;
Signed-off-by: Yingxin Cheng <yingxincheng@gmail.com>
sharded data structures should only be allocated in core#0, or the
program will hang during exit.
Signed-off-by: Yingxin Cheng <yingxincheng@gmail.com>
We can only check for MAJOR.MINOR version of python3 since
FindPython3Libs does not support checking for MAJOR.MINOR.PATCH version
of python3. We also need to make sure we use the PYTHON3 versions of
these variables.
This should fix a regression introduced by c961e00.
Signed-off-by: Boris Ranto <branto@redhat.com>
* refs/pull/27198/head:
vstart: generate environment script suitable for sourcing
cephfs-shell: fix mode of script in tree
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
cdIsInGroup should not be included in the request
and username/password should be an empty string
(instead of null)
Fixes: https://tracker.ceph.com/issues/39110
Signed-off-by: Ricardo Marques <rimarques@suse.com>
* refs/pull/27303/head:
mds: add Octopus cephfs feature bit
mds: verify current release has a cephfs feature bit
mds: add cephfs feature bit for Nautilus
mon: generalize and refactor lambda use
qa: test featureful client with mimic base
qa: remove obsolete snap upgrade tests
Reviewed-by: Zheng Yan <zyan@redhat.com>
iSCSI overview page will now use information
obtained from ceph-iscsi.
Fixes: https://tracker.ceph.com/issues/39024
Signed-off-by: Ricardo Marques <rimarques@suse.com>
to force cmake to use the python3 and python3 modules for building
python3 bindings
on the debian side, it's okay to continue using "-DWITH_PYTHON3=ON", as
- cmake does normalize "ON" to 3
- debian's cmake extension lives on /usr/lib/python3/dist-packages/
not in a specific /usr/lib/python3.x/dist-packages directory
Signed-off-by: Kefu Chai <kchai@redhat.com>
actually cython or python3-cython's dependencies should take care of it.
but we should at least get it right on our side if we check it.
Signed-off-by: Kefu Chai <kchai@redhat.com>
use might have multiple python3 installed, some of them has/have all
dependencies installed and is good enough for building Ceph. we should
not always use the latest python installed in the system and complain that
there is missing dependencies, even if user has installed all the
python3 dependencies for the older python3.
put in other words, if user only installs cython module for python3.4, but
she has both python3.6 and python3.4 in her system. we should not force
her to uninstall python3.6 for installing Ceph.
this change also aligns with MGR_PYTHON_VERSION. i am not applying the
same change to WITH_PYTHON2, because python2 is already stablized. and distros
are not likely to release new python2 releases.
Signed-off-by: Kefu Chai <kchai@redhat.com>
