reserve a few feature bits

Make sure we have a bit of warning before we reach the end times.

Signed-off-by: Sage Weil <sage@redhat.com>
mon: use pre-encoded OSDMap for build_latest_full() MOSDMap message

Do not reencode; use our existing encoded bufferlist.

Signed-off-by: Sage Weil <sage@redhat.com>
osd: warn if reencoding and OSDMap with fewer features than the mon

It is very dangerous to reencode and OSDMap with fewer features than the
mon intended as we may be introducing a different variation of the same
OSDMap epoch into the wild.  Add a build warning here as well as this is
a potentially serious problem.

Signed-off-by: Sage Weil <sage@redhat.com>
osd: use encoded osdmap bl instead of reencoding

We have a good one on disk; there is no reason to do this.

Signed-off-by: Sage Weil <sage@redhat.com>
prevent random people from encoding the OSDMap

This is a safety check: nobody should be encoding OSDMaps except:

 - the mons
 - MOSDMap, when encoding old OSDMaps with legacy encodings
 - ceph-dencoder
 - the OSD

More importantly, nobody should be encoding OSDMap::Incremental except

 - the leader mon

We use a reserved feature bit to indicate that the encoder is enlightened.
Note that we skip this check for legacy encodings, so we don't touch
MOSDMap in this patch.

Signed-off-by: Sage Weil <sage@redhat.com>
add MMonGetOSDMap message

This message lets you explicitly request a range of full or incremental
maps from someone (the monitor, presumably), independent of any other
session state.

Signed-off-by: Sage Weil <sage@redhat.com>
mon/OSDMonitor: handle MMonGetOSDMap

Respond to MMonGetOSDMap with an MOSDMap filled with what we have.

Signed-off-by: Sage Weil <sage@redhat.com>
buffer: add iterator::get_bl()

Signed-off-by: Sage Weil <sage@redhat.com>
osd/OSDMap: encode crc

Note that we include the logic in OSDMap::encode to add data that comes
after the crc, although we do not use it yet.

Also note that we do not yet verify the crc on decode.

Signed-off-by: Sage Weil <sage@redhat.com>
mon/OSDMonitor: populate Incremental::full_crc

When we encode an Incremental, put in the expected crc for the resulting
full OSDMap.

Signed-off-by: Sage Weil <sage@redhat.com>
osd/OSDMap: verify CRC on decode

Signed-off-by: Sage Weil <sage@redhat.com>
rgw: support swift storage policy api

Fixes: #9932

When creating a bucket, set the placement rule according to the
provided X-Storage-Policy http header.

Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
librados: drop useless ver arg to _notify_ack

Signed-off-by: Sage Weil <sage@redhat.com>
librados: define updated watch/notify interface

- new notify callback with the correct values:
  - notify_id
  - watch handle
  - payload
- new notify_ack call
  - not implicit when the callback returns (for new api only)
  - optional payload
- new watch2 call
  - that provides the new callback
- new notify2 call
  - with the right arguments, and optional timeout

A couple refactors in here:
- IoCtx notify_ack is now called unlocked (Note: this will soon change
  with pending Objecter locking changes)
- Objecter notify_ack takes a buffer

TODO:
- no timeout on the individual watch, yet...

Signed-off-by: Sage Weil <sage@redhat.com>
osd: implement notify ack payloads

If the notified send back reply payloads, pass them back to the notifier.

Note that we have changed the on-wire behavior of the watch completion
message a bit: instead of sending the original notify payload back to the
notifier, we send the map of notified to replies.  Note that only users of
the new API will know what to do with the notify acknowledgement
information.  At the same time, we stop sending the original payload.
However, the old API users never saw that data; we were uselessly sending
it over the wire.

Signed-off-by: Sage Weil <sage@redhat.com>
librados: update notify2 API to accept reply payloads

Allow the notify2 callers to provide bufferlists or char ** pointers
so that we can pass the reply buffer back to them.

Signed-off-by: Sage Weil <sage@redhat.com>
ceph_test_rados_api_watch_notify: test notify2 api

Signed-off-by: Sage Weil <sage@redhat.com>
librados: include notifier's gid in notify

The notify replies include the identify of everyone who acked the
notify.  For symmetry, inform the notified client who sent the notify.

Fixes: #9198
Signed-off-by: Sage Weil <sage@redhat.com>
osd: allow multiple watchers/notify replies per client

It is perfectly valid to register multiple watchers via the same
librados client.  Make the notify_replies a multimap to capture all
of the acks.

Signed-off-by: Sage Weil <sage@redhat.com>
librados: unconditionally pass WATCH_NOTIFY to legacy callback

This was always WATCH_NOTIFY; just pass that explicitly.  No need to
pay attention to what's in the message.

Signed-off-by: Sage Weil <sage@redhat.com>