Yingxin Cheng [Thu, 28 Feb 2019 08:40:24 +0000 (16:40 +0800)]
crimson/net: skeleton code for ProtocolV2 logic
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.
Yingxin Cheng [Tue, 19 Mar 2019 14:26:59 +0000 (22:26 +0800)]
test/crimson: improved perf tool for crimson-msgr
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;
Boris Ranto [Thu, 4 Apr 2019 20:00:55 +0000 (22:00 +0200)]
cmake: check for MAJOR.MINOR version of python3
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.
* 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
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
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.
Direct upgrades from Luminous to Octopus are not supported. These snap format
upgrade tests are now only going to be run in the mimic/nautilus branches.
Fixes: http://tracker.ceph.com/issues/39020 Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
Sage Weil [Wed, 3 Apr 2019 19:07:27 +0000 (14:07 -0500)]
Merge PR #27291 into master
* refs/pull/27291/head:
qa/suites/upgrade/nautilus-x-singleton: upgrade mgrs early
qa/suites/upgrade/mimic-x-singleton: upgrade mgrs later
qa/suites: add upgrade/nautilus-x-singleton and symlink from rados/upgrade
qa/suites: move rados/upgrade/mimic-x-singleton to upgrade/ and symlink
Ernesto Puerta [Tue, 26 Mar 2019 18:01:01 +0000 (19:01 +0100)]
mgr/dashboard: unify button/URL actions naming
- Mappings (actually an Enum) created for actions (buttons and other UI elements) and URLs: ActionLabels and URLVerbs.
- An alternative would be to fix/improve the current i18n-polyfill, which only works with literal strings (not even with 'const enums' which become literals after Typescript transpiling).
- Additionally having a predefined file with some strings to translate (actions, verbs, etc) could improve on the 1st of the 2-stage i18n process (as extraction tool has a lot of limitations).
- A corresponding ActionLabelsI18n service with translated labels (it's a service as I haven't found the way to either translate no-const strings (ngx-translate/AST parser failure) or get a static translator).
- This services could/should be extended to cover all strings that are defined in static/globally scoped objects before any I18n provider has been initialized.
- Breadcrumbs are not translated (neither were they before this change). This part remains untackled: using 'proxy' static objects and performing live translation could deal with the issue.
- New URLBuilder service created (following a established pattern in the Java/.NET world) . This should avoid the need of messing with literal URLs and string composition/parsing, and while the front-end is not meant to be consumed by anyone, Angular does not provide any other way for the app to navigate between components, so the URLs are a de-facto interface contract. Unlike this approach is not flawless, it's easier to enforce, while issues coming from free-from strings are really hard to catch.
- This could be further improved by using a router registry/dynamic routing. Most of the routes are trivial.
- As a side effect of these changes, routing module has been refactored and some routes moved to their specific modules (pool, rbd, rgw), via loadChildren and routes.forChild() magic. Now the above mentioned components are lazy-loaded/pre-loaded (it means right after the main code is loaded). This should also decrease the loading time (though probably this is not biggest time eater here).
- As now modules can be loaded multiple times, not only from App module by means of lazy loading, but also from other ones (as PoolModule loads BlockModule to get QoS widgets in Pool windows), now lazy loaded modules include 2 NgModules (one with imports: RouterModule.forChild(routes), meant for lazy-loading, and another without routes).
- Caveat: Some parts might not be (fully) translated (NFS, iSCSI, mirroring), as there's been ongoing work on them and it's hard to keep up with the new code.
These changes will be a waste of time if the new code does not take benefit from/adheres to it, so I'm still figuring out how to spread this (nothing really fancy to demo). Maybe adding some checks/harnessing to enforce the new naming convention (ideas greatly welcome here).
install-deps,rpm: enable devtoolset-8 on aarch64 also
in 5ae3b06e, we left aarch64 with devtoolset-7, but aarch64 builders are
also suffering from http://tracker.ceph.com/issues/38892. so i installed
devtoolset-8 on all aarch64 builders manually from the rpm packages
downloaded from koji builder: