build/ops: conditionalize rgw Beast frontend so it isn't built on s390x architecture
Reviewed-by: Willem Jan Withagen <wjw@digiware.nl>
Reviewed-by: Kefu Chai <kchai@redhat.com>
The following warning appears during make:
ceph/src/test/msgr/test_msgr.cc: In member function ‘virtual void MessengerTest_MarkdownTest_Test::TestBody()’:
ceph/src/test/msgr/test_msgr.cc:1474:46: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
CHECK_AND_WAIT_TRUE(srv_dispatcher.count > last + 1);
~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
ceph/src/test/msgr/test_msgr.cc:54:9: note: in definition of macro ‘CHECK_AND_WAIT_TRUE’
if (expr) \
^~~~
ceph/src/test/msgr/test_msgr.cc:1475:30: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (srv_dispatcher.count == last) {
~~~~~~~~~~~~~~~~~~~~~^~~~~~~
Signed-off-by: Jos Collin <jcollin@redhat.com>
The following warning appears during make:
ceph/src/test/test_denc.cc:669:5: required from here
ceph/src/googletest/googletest/include/gtest/gtest.h:1530:28: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
ceph/src/googletest/googletest/include/gtest/gtest.h:1510:7:
if (val1 op val2) {\
Signed-off-by: Jos Collin <jcollin@redhat.com>
In particular, we want the attrs (map<string,bufferptr>) to be a deep
decode so that we do not pin this buffer, and so that any changed attr
will free the previous memory.
Signed-off-by: Sage Weil <sage@redhat.com>
Otherwise we can assert out when we try to join a thread that
hasn't started.
- move everything into _kv_start() and _kv_stop()
- separate stop bools for each thread
- wait until thread starts before signalling stop (and potentially calling
join()).
Signed-off-by: Sage Weil <sage@redhat.com>
_deferred_replay needs the kv_sync_thread to complete IOs; start them
just for that, but then shut them down again. (We might revisit that
later if/when fsck does any sort of repair.)
Signed-off-by: Sage Weil <sage@redhat.com>
- OSDMap encode and decode translate between the flags and int
representations.
- OSDMap::Incremental only does decode; we do not expect to ever encode
an incremental osdmap for an old osd that sets any of these flags.
- the 'osd set' command still lets you set the jewel and kraken flags,
but not luminous.
- OSDMap::apply_incremental handles the conversion of legacy require flags
to the new field if the jewel or kraken flags have to be set before
starting the osd upgrade.
- clear out the legacy flags when we make the luminous transition only;
until then we keep using the old flag in the encoded and decoded version
(although the require_osd_release field will be accurate in memory in all
cases).
Signed-off-by: Sage Weil <sage@redhat.com>
Note that we only allow setting this to 'luminous'. If the 'jewel' or 'kraken'
flags need to be set that can be done through the legacy interface.
Signed-off-by: Sage Weil <sage@redhat.com>
Instead of eating up a flag for each release, which is super-awkward and
annoying, just keep a numeric release version min.
Signed-off-by: Sage Weil <sage@redhat.com>
Since the Beast frontend uses boost::context which is not supported on
s390x.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Signed-off-by: Kefu Chai <kchai@redhat.com>
boost::context is currently (1.63) unsupported for s390x and anyway
it makes sense to conditionalize Boost components so they are only
built with the Ceph components that need them (like is already being
done for mgr).
Fixes: http://tracker.ceph.com/issues/20048
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Signed-off-by: Tim Serong <tserong@suse.com>
Signed-off-by: Casey Bodley <cbodley@redhat.com>
Signed-off-by: Kefu Chai <kchai@redhat.com>
common/iso_8601.cc: Make return expression Clang compatible
Reviewed-By: Adam C. Emerson <aemerson@redhat.com>
Reviewed-by: Kefu Chai <kchai@redhat.com>
- Buffer.h is needed to prevent Clang seriously complaining
about missing and wrong forward declarations of
ceph::buffer:ptr
including buffer_fwd.h does not help.
Signed-off-by: Willem Jan Withagen <wjw@digiware.nl>
- During include cleanup just a too bit much was removed for FreeBSD
to get things compiled.
This redoes some of the includes.
Tracker: http://tracker.ceph.com/issues/19883
Signed-off-by: Willem Jan Withagen <wjw@digiware.nl>
C VLAs are not supported in C++. However, the GNU compiler allows
them as an extension, which it does not warn about when not in
pedantic mode. Unfortunately, it's easy to accidentally write
a VLA, even unintentionally-- adding this warning will help us
catch that.
Signed-off-by: Jesse Williamson <jwilliamson@suse.de>
