for rendering sequence-diagram. unlike ditaa, seqdiag allows us to
create sequence-diagram without worrying about the layout. and the
syntax is quite like that of dot.
Signed-off-by: Kefu Chai <kchai@redhat.com>
just in case, otherwise we could have
File "/home/docs/checkouts/readthedocs.org/user_builds/ceph/envs/42577/lib/python3.8/site-packages/sphinxcontrib/ditaa.py", line 200, in html_visit_ditaa
render_ditaa_html(self, node, node['code'], node['options'])
File "/home/docs/checkouts/readthedocs.org/user_builds/ceph/envs/42577/lib/python3.8/site-packages/sphinxcontrib/ditaa.py", line 177, in render_ditaa_html
fname, outfn = render_ditaa(self, code, options, prefix)
File "/home/docs/checkouts/readthedocs.org/user_builds/ceph/envs/42577/lib/python3.8/site-packages/sphinxcontrib/ditaa.py", line 141, in render_ditaa
p = Popen(ditaa_args, stdout=PIPE, stdin=PIPE, stderr=PIPE)
File "/home/docs/.pyenv/versions/3.8.6/lib/python3.8/subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/home/docs/.pyenv/versions/3.8.6/lib/python3.8/subprocess.py", line 1702, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
OSError: [Errno 8] Exec format error: '/usr/bin/ditaa'
Signed-off-by: Kefu Chai <kchai@redhat.com>
osd/PGLog: set acceptable rollback_info_trimmed_to for pg of replicated pool
Reviewed-by: Samuel Just <sjust@redhat.com>
Reviewed-by: Kefu Chai <kchai@redhat.com>
legacy-option-headers provides global_legacy_options.h, which is in turn
required for building crimson-admin.
Signed-off-by: Kefu Chai <kchai@redhat.com>
set(dpdk_LIBRARIES) does not reset this variable, it leaves it
unchanged.
if pkg-config manages to find DPDK libraries, dpdk_LIBRARIES would be
set with a string like "rte_node;rte_graph;..." by
pkg_check_modules(dpdk QUIET libdpdk).
but we would want to set this variable to the import paths of the
required libraries. so reset it before appending them to this variable.
this change helps to address the build failure when building Ceph with
DPDK installed into system along with its .pc file.
Signed-off-by: Kefu Chai <kchai@redhat.com>
<experimental/iterator> was included for std::experimental::make_ostream_joiner
in a968f65d78. but the code using
std::experimental::make_ostream_joiner was later rewritten in
ab0d8f2ae9, in which
std::experimental::make_ostream_joiner is not used anymore.
so let's drop it.
Signed-off-by: Kefu Chai <kchai@redhat.com>
- ubuntu focal ships libcryptsetup-dev (2:2.2.2),
- centos 8 app stream comes with cryptsetup-devel-2.3.3.
- openSUSE Leap 15.3 packages libcryptsetup-devel-2.3.4
- openSUSE Leap 15.2 packages libcryptsetup-devel-2.0.5
so we can drop the support for libcryptsetup < 2.0.5
see also ea3c1bfb9e
Signed-off-by: Kefu Chai <kchai@redhat.com>
This diff makes the following changes:
- FSMap::compat is now just a "default compat" of currently unknown
utility. It is used when constructing a new file system but does
not really have any effect or current use.
- The `mds compat *` CLI commands are deprecated. They manipulate
the default compat which has no useful effect.
- Each MDS sends its compat to the mons in its beacon. This is from
MDSMap::get_compat_set_all() at MDS boot. This CompatSet does not
change for the duration of the MDS lifetime.
- Mons record each MDS compat in the FSMap to inform standby failover.
An MDS is only promoted if it is compatible with the file system
compat.
- Mons upgrade (merge) the file system compat when (a) the number of
*in* MDS is 1 (effected by max_mds=1) and (b) the mons are promoting a
standby with a new compat. A file system is never upgraded when there
is more than 1 rank to prevent two MDS with incompatible compat.
- A suite of `fs compat` commands exist to manipulate the file system
compat. These exist mostly for testing.
The consequence of these changes is that the upgrade procedure for MDS
can be updated to no longer require turning off all MDS but rank 0
before performing any upgrades. A CompatSet change would cause all MDS
receiving the new MDSMap to suicide due to incompatibility (if so).
Instead, the monitors will no longer assign an incompatible MDS to a
file system and enforce an upgrade procedure if incompatibilities exist.
Fixes: https://tracker.ceph.com/issues/49720
Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
The MDS_FEATURE_INCOMPAT_INLINE feature indicates that an MDS knows how
to read/write inline data and that the file system may have it. The
separate setting for inline_data protects this file system feature.
Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
It's not necessary to distribute a CompatSet with the null mdsmap. We
only need to communicate that the MDS is not part of any map.
Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
