Patrick Donnelly [Thu, 15 Jul 2021 01:02:20 +0000 (18:02 -0700)]
mon/MDSMonitor: propose if FSMap struct_v is too old
To flush older versions which may still be an empty MDSMap (for clusters
that have never used CephFS), we need to force a proposal so older
versions of the struct are trimmed.
This is the main fix of this branch. We removed code which processed old
encodings of the MDSMap in the mon store via 60bc524. That broke old
ceph clusters which never used CephFS (see cited ticket below). This is
because the initial epoch is an empty MDSMap (back in Infernalis/Hammer)
that is never updated. So, the fix here is to just do proposals
periodically until all of the old structs are automatically trimmed by
the mons.
Fixes: 60bc524827bac072658203e56b1fa3dede9641c5 Fixes: https://tracker.ceph.com/issues/51673 Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
Patrick Donnelly [Wed, 14 Jul 2021 20:31:21 +0000 (13:31 -0700)]
mon/MDSMonitor: return mon_mds_force_trim_to even if equal to current epoch
The PaxosService code already excludes the value returned by
PaxosService::get_trim_to as the upper bound of the range of epochs to
trim. Without this fix, you need to set mon_mds_force_trim_to to one
greater than the epoch you want to trim _and_ force the current epoch to
be one greater than that; the net result being that you can only force
trimming up to 2 epochs behind the current epoch.
This change is helpful for resolving issue 51673, but not strictly
necessary.
Related-to: https://tracker.ceph.com/issues/51673 Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
Patrick Donnelly [Wed, 14 Jul 2021 16:16:26 +0000 (09:16 -0700)]
qa: add nofs upgrade suite
This adds an upgrade suite to ensure that a Ceph cluster without a
CephFS file system does not blow up on upgrade (in particular, that the
MDSMonitor does not trip). This was developed to potentially reproduce
tracker 51673 but the actual cause for that issue was an old encoding
for the MDSMap which was obsoleted in Pacific. You must create a cluster
older than the FSMap (~Hammer or Infernalis) to reproduce. In any case,
this upgrade suite may be useful in the future so let's keep it!
Related-to: https://tracker.ceph.com/issues/51673 Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
Sage Weil [Tue, 27 Jul 2021 18:11:56 +0000 (14:11 -0400)]
Merge PR #42406 into master
* refs/pull/42406/head:
mgr/nfs: remove unused 'realm' arg for 'nfs export create rgw'
doc/mgr/rook: update title
doc/mgr/nfs: reference customizing ingress
doc/mgr/nfs: add section for manual ganesha config; reframe
doc/mgr/nfs: document ingress in more detail
doc/mgr/nfs: typo
doc/mgr/nfs: add note about incomplete ingress
qa/suites/orch/cephadm: add rgw nfs export test
mgr/cephadm: ingress: tolerate no daemons
mgr/nfs: add --squash option to 'nfs export create rgw ...'
mgr/nfs: use bucket owner creds for rgw bucket export
mgr/cephadm: use new CEPH_IMAGE_TYPES for all daemons using ceph container image
qa/tasks/python: simple task to run python code
doc/mgr/nfs: revisions
mgr/nfs/export: nicer exceptions on cap update
Sage Weil [Mon, 19 Jul 2021 17:46:38 +0000 (13:46 -0400)]
mgr/nfs: use bucket owner creds for rgw bucket export
The bucket owner can always read/write to the bucket, so use those creds
for the export. This is less complicated than setting up a dedicated
user anyway.
replace strict_iecstrtoll(const char *str,..) with
strict_iecstrtoll(std::string_view, ..). which is more convenient.
and both of them share the same implementation:
strict_sistrtoll() is but an alias of strict_si_cast<uint64_t>(..),
let's just drop the former. there are way too many thin wrappers in
strtol.{h,cc}. they don't offer lots of benefit to us.
this variant is better than strict_si_cast(const char*), because:
* we can just pass std::string to it, as std::string_view can be
constructed from a std::string implicitly
* strict_si_cast(std::string_view, ..) is the underlying
implementation of strict_si_cast(const char*,..), so less
indirection helps with the readability.
rgw,mon,common/strtol: use strict_iec_cast(std::string_view, ..)
this variant is better than strict_iec_cast(const char*), because:
* we can just pass std::string to it, as std::string_view can be
constructed from a std::string implicitly
* strict_iec_cast(std::string_view, ..) is the underlying
implementation of strict_iec_cast(const char*,..), so less
indirection helps with the readability.
* rgw,mon: use strict_iec_cast(std::string_view, ..) instead.
vstart.sh: set objectstore to "cyanstore" if --cyanstore is specified
in e6ed65db8b4e0a2f8026c2e35a12dd292c5f2b8c, "cyanstore" is added to the
help message of vstart.sh, but we should also check for this option, and
set the ceph option accordingly.
in this change, the option is checked and "objectstore" is updated
accordingly.
In file included from ../src/common/config.h:27,
from ../src/crimson/common/config_proxy.h:8,
from ../src/crimson/osd/main.cc:23:
../src/common/config_values.h: In copy constructor ‘ConfigValues::ConfigValues(const ConfigValues&)’:
../src/common/config_values.h:19:7: note: variable tracking size limit exceeded with ‘-fvar-tracking-assignments’, retrying without
19 | class ConfigValues {
| ^~~~~~~~~~~~
* define OpenLDAP::OpenLDAP, so this library can be consumed in a simpler way.
* use OpenLDAP::OpenLDAP instead of OpenLDAP_LIBRARIES when appropriate
* do not link against unused ${OpenLDAP_LIBRARIES}
it was changed from a shared library to object library back in 3c0bba40b2fcc36a02bfe89647231e8983819a72, because we wanted to link both
rgw_a and rgw_admin_user against it.
but now that rgw_admin_user was dropped in c89b59428e66ae6d89d1fd27a4280045c57251cb, let's compile rgw_common
as a static library. it'd be much easier for us to apply various compile
options and linkages to it this way.
cmake: build rgw_kmip_client_impl as part of radosgw
instead compiling rgw_kmip as an object library, just include
rgw_kmip_client_impl.cc in radosgw. simpler this way, as
rgw_kmip_client_impl.cc includes rgw/rgw_common.h. while rgw_common.cc
is indirectly included by ${rgw_libs} as a part of rgw_a, so
it would be simpler if we just compile rgw_kmip_client_impl.cc
as a part of radosgw, and let radosgw link against ${rgw_libs},
which are able to take care of the include directories of 3rd party
libraries, like spawn/spawn.hpp, which is pulled in by rgw/rgw_common.h.
because fmt is packaged in EPEL, while librados is packaged
in RHEL, so we cannot have fmt as a runtime dependency of librados.
to address this issue, we should compile librados either with static library
or with header-only library of fmt. but because the fedora packaging
guideline does no encourage us to package static libraries, and it would
be complicated to package both static and dynamic library for fmt.
the simpler solution would be to compile Ceph with the header-only
version of fmt.
in this change, we compile ceph with the header-only version of fmt
on RHEL to address the runtime dependency issue.
* an interface library named "fmt-header-only" is introduced. it brings
the support to the header only fmt library.
* fmt::fmt is renamed to fmt
* an option named "WITH_FMT_HEADER_ONLY" is introduced
* fmt::fmt is an alias of "fmt-header-only" if "WITH_FMT_HEADER_ONLY"
is "ON", and an alias of "fmt" otherwise.
because fmt is packaged in EPEL, while librados is packaged
in RHEL, so we cannot have fmt as a runtime dependency of librados.
to address this issue an option "WITH_FMT_HEADER_ONLY" is introduced, so
that we can enable it when building Ceph with the header version of fmt.
and the built packages won't have runtime dependency of fmt.
We don't need to run an extra command (mgr module ls) to obtain the mgr
modules list since we already have this information in the mgr_map.
This workflow is already done for the monitoring stack or for configuring
the iscsi integration within the dashboard (during creation) via the
config_dashboard method.
The mgr_map is mocked in the tests with the dashboard module enabled so we
don't need _mon_command_mock_mgr_module_ls anymore.
rpm: drop use of $FIRST_ARG in ceph-immutable-object-cache
The use of $FIRST_ARG was probably required because the SUSE-specific
%service_* rpm macros were playing tricks on the shell positional parameters.
This is bad practice and error-prone, so let's assume that no macros should do
that anymore and hence it's safe to assume that positional parameters remain
unchanged after any rpm macro call.