quite a few base classes with virtual functions mark their destructor
non-virtual and `protected` for better performance, as seastar destruct
them via the concrete type of the instance.
so let's disable this warning. but, please note, this newly added
CXX_FLAG in `Seastar_CXX_FLAGS` won't be populated to crimson, as it is
only added to the CXX_FLAGS used for compiling seastar itself. so we still
have `-Wnon-virtual-dtor` warnings when compiling crimson as long as seastar
headers are included.
so to silence these warnings, we need to add it also to `crimson::cflags`,
probably it's worth trading the noise caused by seastar's optimizations
with the potentially useful warning messages caused by our oversights.
in my case, there are over 300 lines of warnings split by GCC-10, so i
still think it'd be better to add it also to crimson to increase the
signal-to-noise ratio. we can aways remove it every once in a while to
check if we forget to mark the destructor of a base class `virtual`.
Signed-off-by: Kefu Chai <kchai@redhat.com>
in the latest version of seastar, we are not able to construct a
`seastar::pollable_fd_state` directly, as its constructor is now
`protected`, and only the reactor is able to create an instance of
`seastar::pollable_fd_state` now.
and `seastar::readable_eventfd` offers all we need to get notified
by reactor in an alien world. so let's used it instead.
Signed-off-by: Kefu Chai <kchai@redhat.com>
This ticket seems to suggest that (1) the root cause is related to an
exec that is orphaned and screws up the container state (due to, e.g., ssh
dropping, or a timeout), (2) -f may be needed, sometimes, to recover, and
(3) newer versions fix it.
https://github.com/containers/libpod/issues/3226
Way back in 26f9fe54cb we found that using
-f the first time around was a Bad Idea, so we'd rather avoid this.
Instead, just avoid triggering the bug.
Signed-off-by: Sage Weil <sage@redhat.com>
- We keep ServiceDescription around unmodified (although it will need some
cleanup later)
- We add DaemonDescription, and clean out the service-related ambiguities
- Add a new list_daemons() method for Orchestrator
- Add a new 'ceph orch ps' command
- In cephadm, drop get_services(), and implement list_daemons()
- a million changes to make this work
- Adjust health alert and option names
Signed-off-by: Sage Weil <sage@redhat.com>
* refs/pull/33205/head:
mgr/cephadm: Bail if we cannot find a host for services
mgr/cephadm: fix placement of new daemons (mds,rgw,rbd-m)
mgr/orchestrator: minor change to improve type checking
mgr/cephadm: test_cephadm: simplify matching strings
Reviewed-by: Sage Weil <sage@redhat.com>
This is a regression introduced by 634a709
The lvm batch command fails to prepare the OSDs on the created LV.
When using lvm batch, the LV/VG are created prior the OSD prepare.
During that creation, multiple tags are set with null value.
$ lvs -o lv_tags --noheadings
ceph.cluster_fsid=null,ceph.osd_fsid=null,ceph.osd_id=null,ceph.type=null
Since we call is_ceph_device which returns True if the ceph.osd_id LVM
tag exists but doesn't test the value then we raise an execption.
When the tag value is set to 'null' then we can consider that the device
isn't part of the ceph cluster (because not yet prepared).
Closes: https://tracker.ceph.com/issues/44069
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
