msgr: some SimpleMessenger docs

Document basic modules and the lock ordering.

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

cephtool: send keepalive to tell target

If we 'ceph tell <foo> ...' to a non-monitor, we need to send keepalives to
ensure we detect a tcp drop.  (Not so for monitors; monclient already does
its own keepalive thing.)

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

cephtool: retry 'ceph tell <who> ...' command if connection fails

It was easy to reproduce a hang with 'ceph osd tell osd.0 foo' and
messenger failure injection.

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

cephtool: set messenger policy

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

cephtool: fix deadlock on fault when waiting for osdmap

send_command() was blocking for the osdmap, and also called from the
connect callback.  Instead, re-call it from the handle_osd_map() callback
so that it never blocks.

This was easy to trigger with 'ceph osd tell osd.0 foo' and ms failure
injection.

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

msg/Pipe: if we send a wait, make sure we follow through

Mark our outgoing connection attempt if we send a WAIT in accept().  This
ensures we don't go to standby or closed in fault() on the outgoing
connection for any reason.

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

client: handle fault during session teardown

We may have a sequence like:

 - client does REQUEST_CLOSE
 - mds sends reply
 - connection faults, client does get reply
 - mds closes out its connection
 - client tries to reconnect/resend, gets RESET_SESSION
   -> continues lamely waiting

If we get a session reset and we were asking to close the connection,
we are happy--it was closed.

This was exposed with ceph-fuse start/stop tests with socket failure
injection.

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

msg/Pipe: make STANDBY behavior optional

In particular, lossless_peers should use STANDBY, but lossless_clients
should reconnect immediately since they are already doing their own session
management.

Specifically, this fixes the problem where the Client tries to open a
connection to the MDS and faults after delivering its OPEN_SESSION message
but before it gets the reply: the session isn't open yet, so it isn't
pinging.  It could, but it is simpler and faster to make the msgr layer
keep the connection open instead of waiting for a periodic keepalive.

Fixes: #2824
Signed-off-by: Sage Weil <sage@inktank.com>

msg/Pipe: go to STANDBY on lossless accept fault

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

msg/Pipe: go to standby on lossless server connection faults

Go directly to the STANDBY state, and print a more accurate message.
Otherwise, we do the same check in writer() and go to STANDBY then.  This
is less confusing.

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

osd: reopen heartbeat connections when they fail

If we have an active peer whose Connection fails, open a new one.  This
is necessary now that a lossy client connection does not automatically
reopen on its own (which is necessary to avoid races with session-based
lossy clients and the ms_handle_reset callback).

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

msg/Pipe: fix leak of Connection in ctor

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

msgr: close get_connection() race

This could null deref if the Pipe is registered but failed.

We need to loop here because the Pipe vs Connection stuff sucks; hopefully
this gets fixed up soonish.

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

msgr: drop CLOSED checks during queueing

AFAICS these checks are pointless.  There should be no harm in queueing
messages on a closed connection; they'll get cleaned up when it is
deregistered.  Moreover, the *queuer* shouldn't be the one who has to
unregister a Pipe.

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

msgr: simplify submit_message()

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

msgr: do not reopen failed lossy Connections

There was a race where:

 - sending stuff to a lossy Connection
 - it fails, and queues itself for reap, queues a RESET event
 - reaper clears the Pipe
 - some thread queues new messages and the Pipe is reopened, messages sent
 - RESET event delivered to dispatch, connection is closed and reopened.

The result was that messages got sent to the OSD out of order during the
window between the fault() and ms_handle_reset() getting called.  This will
prevent that.

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

msg/Pipe: unregister pipe immediately on fault; fix mark_down

This fixes a problem where:

 - pipe faults, con->pipe is cleared
 - ms_handle_reset tries to mark_down, but it doesn't know the pipe

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

msg/Pipe: disconnect Pipe from lossy Connection immediately on failure

When we have a lossy connection failure, immediately disconnect the Pipe
and set the Connection failed flag.  There is no reason to wait until the
reaper comes along.

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

msg/Connection: add failed flag for lossy Connections

If a lossy Connection fails and we disconnect the Pipe, set a failed flag.

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

msg/DispatchQueue: fix locking in dispatch thread

The locking was awkward with locally delivered messages.. we dropped dq
lock, inq lock, re-took dq lock, etc.   We would also take + drop + retake
+ drop the dq lock when queuing events.  Blech!

Instead:

 * simplify the queueing of cons for the local_queue
 * dequeue the con under the original dq lock
 * queue events under a single dq lock interval, by telling
   local_queue.queue() we already have it.

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

test_stress_watch: verify that the watch operation isn't slow

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

msgr: indicate whether clients are lossy

We need to know whether the client is lossy before we connect to the peer
in order to know whether to deliver a RESET event or not on connection
failure.  Lossy clients get one, lossless do not.

And in any case, we know ahead of time, so we may as well indicate as much
in the Policy.

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

msgr: do not discard_queue in Pipe reaper

The IncomingQueue can live beyond the Pipe.  In particular, there is no
reason not to deliver messages we've received on this connection even
though the socket has errored out.

Separate incoming queue discard from outgoing, and only do the latter in
the reaper.

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

msg/IncomingQueue: make the pipe parent informational only

Use this pointer only for debug output prefix; do not dereference, as we
may live beyond the original parent.

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

msg/DispatchQueue: give IncomingQueue ref to queue

We want to be able to queue an event (e.g., RESET) and deliver it even
after the Pipe is destroyed.

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

msg/DispachQueue: hold lock in IncomingQueue::discard_queue()

This prevents races with the dispatch thread, among other things.

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

msg: kill tcp.{cc,h}

Move the remaining comparator into msg_types.h and kill this off.

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

msg/DispatchQueue: cleanup debug prefix

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

msg/Pipe: move tcp_* functions into Pipe class

This lets us print nice debug prefixes.  It also calls BS on the
Pipe vs tcp.cc separation.

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

msgr: move Accepter into separate .cc

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

msg/Pipe: get_state_name()

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

msgr: rework accept() connect_seq/race handling

We change a couple of key things here:

 * If there is a matching connect_seq and the existing connection is in OPEN (or
   STANDBY; same thing + a failure), we send a RETRY_SESSION and ask the peer to
   bump their connect_seq.  This handles the case where there was a race, our
   end successfully opened, but the peer's racing attempt was slowly processed.
 * We always reply with connect_seq + 1.  This handles the above case
   more cleanly, and lets us use the same code path.

Also avoid duplicating the RETRY_SESSION path with a goto.  Beautiful!

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

mds: fix race in connection accept; fix con replacement

We solve two problems with this patch.  The first is that the messenger
will now reuse an existing session's Connection with a new connection,
which means that we don't want to change session->connection when we
are validating an authorizer.  Instead, set (but do not change) it.

We also want to avoid a race where:

 - mds recovers, replays Sessions with no con's
 - multiple connection attempts for the same session race in the msgr
 - both are authorized, but out of order
 - Session->connection gets set to the losing attempt's Connection*

Instead, we take advantage of an accept event that is called only for
accepted winners.

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

msgr: queue accept event when pipe is accepted

Queue an event when an incoming connection is accepted.

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

msg/DispatchQueue: queue and deliver accept events

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

dispatcher: new 'accept' event type

Create a new event type when we successfully accept a connection.  This is
distinct from the authorizor verification, which may happen for multiple
racing connection attempts.  In contrast, this will only happen on those
that win the race(s).  I don't think this is that important for stateless
servers (OSD, MON), but it is important for the MDS to ensure that it keeps
its Session con reference pointing to the most recently-successful
connection attempt.

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

msgr: drop unnecessary (un)locking on queuing connection events

This used to be necessary because the pipe_lock was used when queueing
the pipe in the dispatch queue.  Now that is handled by IncomingQueue's
own lock, so these can be removed.

By no longer dropping the lock, we eliminate a whole category of potential
hard-to-debug races.  (Not that any were observed, but now we dno't need to
worry about them.)

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

msgr: move dispatch thread into DispatchQueue

The DispatchQueue class now completely owns message delivery.  This is
cleaner and lets us drop the redundant destination_stopped flag from
msgr (DQ has its own stop flag).

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

msgr: simplify checks for queueing connection events

Looking through git history it is not clear exactly how these checks
came to be.  They seem to have grown during the multiple-entity-per-rank
transition a few years back.  I'm not fully convinced they are necessary,
but we will keep them regardless.

Push checks into DispatchQueue and look at the local stop flag to
determine whether these events should be queued.  This moves us away from
the kludgey SimpleMessenger::destination_stopped flag (which will soon
be removed).

Also move the refcount futzing into the DispatchQueue methods.  This makes
the callers much simpler.

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

msgr: remove unnecessary accept check

We don't need to worry about racing with shutdown here; the cleanup
procedure will stop the accepter thread before cleaning up all the
pipes.

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

msgr: remove obsolete dead path

This hasn't triggered in years.

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

msgr: uninline ctor and dtor

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

msgr: move Pipe, DispatchQueue into separate files

These don't need to be subclasses of SimpleMessenger.  Separate!

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

msgr: simplify IncomingQueue creation, pointers

 * create it via DispatchQueue
 * keep pointer to parent DispatchQueue
 * drop now-useless contextual arguments to most methods

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

msgr: use local IncomingQueue instead of Pipe

Simpler, cleaner.  No need for the rest of the Pipe crap.  We just need to
queue messages for ourselves.

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

msgr: use explicit Connection for messages sent to ourself

Move to an explicit Connection for messages sent to ourselves, instead of
using the one on the local_pipe (which we'll remove shortly).

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

msgr: take over existing Connection on Pipe replacement

If a new pipe/socket is taking over an existing session, it should also
take over the Connection* associated with the existing session.  Because
we cannot clear existing->connection_state, we just take another reference.

Clean up the comments a bit while we're here.

This affects MDS<->client sessions when reconnecting after a socket fault.
It probably also affects intra-cluster (osd/osd, mds/mds, mon/mon)
sessions as well, but I did not confirm that.

Backport: argonaut
Signed-off-by: Sage Weil <sage@inktank.com>

msgr: restart_queue when replacing existing pipe and taking over the queue

The queue may have been previously stopped (by discard_queue()), and needs
to be restarted.

Fixes consistent failures from the mon_recovery.py integration tests.

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

msgr: choose incoming connection if ours is STANDBY

If the connect_seq matches, but our existing connection is in STANDBY, take
the incoming one.  Otherwise, the other end will wait indefinitely for us
to connect but we won't.

Alternatively, we could "win" the race and trigger a connection by sending
a keepalive (or similar), but that is more work; we may as well accept the
incoming connection we have now.

This removes STANDBY from the acceptable WAIT case states.  It also keeps
responsibility squarely on the shoulders of the peer with something to
deliver.

Without this patch, a 3-osd vstart cluster with
'ms inject socket failures = 100' and rados bench write -b 4096 would start
generating slow request warnings after a few minutes due to the osds
failing to connect to each other.  With the patch, I complete a 10 minute
run without problems.

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

msgr: preserve incoming message queue when replacing pipes

If we replace an existing pipe with a new one, move the incoming queue
of messages that have not yet been dispatched over to the new Pipe so that
they are not lost.  This prevents messages from being lost.

Alternatively, we could set in_seq = existing->in_seq - existing->in_qlen,
but that would make the other end resend those messages, which is a waste
of bandwidth.

Very easy to reproduce the original bug with 'ms inject socket failures'.

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

msgr: move dispatch_entry into DispatchQueue class

A bit cleaner.

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

msgr: move incoming queue to separate class

This extricates the incoming queue and its funky relationship with
DispatchQueue from Pipe and moves it into IncomingQueue.  There is now a
single IncomingQueue attached to each Pipe.  DispatchQueue is now no
longer tied to Pipe.

This modularizes the code a bit better (tho that is still a work in
progress) and (more importantly) will make it possible to move the
incoming messages from one pipe to another in accept().

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

msgr: make D_CONNECT constant non-zero, fix ms_handle_connect() callback

A while ago we inadvertantly broke ms_handle_connect() callbacks because
of a check for m being non-zero in the dispatch_entry() thread.  Adjust the
enums so that they get delivered again.

This fixes hangs when, for example, the ceph tool sends a command, gets a
connection reset, and doesn't get the connect callback to resend after
reconnecting to a new monitor.

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

msgr: fix pipe replacement assert

We may replace an existing pipe in the STANDBY state if the previous
attempt failed during accept() (see previous patches).

This might fix #1378.

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

msgr: do not try to reconnect con with CLOSED pipe

If we have a con with a closed pipe, drop the message.  For lossless
sessions, the state will be STANDBY if we should reconnect.  For lossy
sessions, we will end up with CLOSED and we *should* drop the message.

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

msgr: move to STANDBY if we replace during accept and then fail

If we replace an existing pipe during accept() and then fail, move to
STANDBY so that our connection state (connect_seq, etc.) is preserved.
Otherwise, we will throw out that information and falsely trigger a
RESETSESSION on the next connection attempt.

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

mon: initialize quorum_features

This could cause us to incorrectly encode new features into the monstore
that an old mon won't understand.

This is overly conservative; we probably need to persist the set of quorum
features that are supported and use those.

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

OSD::do_command: unlock pg only if we had it

Signed-off-by: Samuel Just <sam.just@inktank.com>

MOSDSubOp: set hobject_incorrect_pool in decode_payload

Signed-off-by: Samuel Just <sam.just@inktank.com>

filestore: initialize m_filestore_do_dump

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

osdmap: check new pool name on rename

Ensure the new pool name doesn't already exist, both in the current and
project map.

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

osd: handle pool name changes properly

 * Remove the old name from the name->id map.

Fixes: #2676
Signed-off-by: Sage Weil <sage@inktank.com>

mon: 'osd pool rename <oldname> <newname>'

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

rest-bench: mark request as complete later

We marked a request as complete in the callback, however
it might be that we're still inside S3_runall_request_context()
which means that request is not really complete yet.
Possibly fixes bug #2652.

Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>

DBObjectMap: clones must inherit spos from parent

Signed-off-by: Samuel Just <sam.just@inktank.com>

filestore: sync object_map object in lfn_remove when nlink > 1

In the following sequence:

1) create (a, 1)
2) setattr (a, 1)
3) link (a, 1), (b, 1)
4) remove (a, 1)

If we play 1-4 and then replay 1-4 again, we will end up removing
(b, 1)'s attributes since nlink for (a, 1) the second time through
is 1.  We fix this by marking spos on the object_map header for
(a, 1) when we remove (a, 1) but not eh attributes.

Signed-off-by: Samuel Just <sam.just@inktank.com>

debian: move metadata server into ceph-mds

Also adjust the recommends and depends, so that libcephfs1 and ceph-fuse
hang off of ceph-mds instead of ceph.

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

debian: move mount.ceph and cephfs into ceph-fs-common

Based on patches from Laszlo Boszormenyi (GCS) <gcs@debian.hu>.

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

debian: arch linux-any

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

debian: build with libnss instead of crypto++

Signed-off-by: Laszlo Boszormenyi (GCS) <gcs@debian.hu>

doc/config-cluster/authentication: keyring default locations, simplify key management

- keyrings have new default locations that everyone should use.
- the user key setup is vastly simplified if you use the
  'ceph auth get-or-create' command.

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

mon: MonmapMonitor: Use default port when the specified on 'add' is zero

Fixes a bug triggered by using the ceph tool to 'mon add' with a port set
to zero. We now default to the monitor's default port (6789) instead, and
we will fail if that port is already assigned to some other monitor.

Fixes: bug #2661
Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>

OSD: disconnect_session_watches: handle race with watch disconnect

Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Tested-by: Stefan Priebe <s.priebe@profihost.ag>

mon: don't tick the PaxosServices if we are currently slurping.

They aren't prepared to deal with the on-disk state being inconsistent.

Signed-off-by: Greg Farnum <greg@inktank.com>

objecter: do not feed session to op_submit()

The linger_send() method was doing this, but it is problematic because the
new Op doesn't get its pgid or acting vector set correctly.  The result is
that the request goes to the right OSD, but has the wrong pgid, and makes
the OSD complain about misdirected requests and drop it on the floor.  It
didn't affect the test results because we weren't testing whether the
watch was working in that case.

Instead, we'll just recalculate and get the same value the parent linger
op did.  Which is fine, and goes through all the usual code paths so
nothing is missed.

Also, increment num_homeless_ops before we recalc_op_target(), so that we
don't (harmlessly, but confusingly) underflow.

Fixes: #2022
Signed-off-by: Sage Weil <sage@inktank.com>

ObjectStore::Transaction: initialize pool_override in all constructors

use_pool_override and pool_override weren't initialized in these two
constructors.

Signed-off-by: Samuel Just <sam.just@inktank.com>

osd_types.cc: remove hobject_t decode asserts

These asserts were useful for ensuring that pool is passed
in in the correct places, but they prevent the encoder
testing from working.

Signed-off-by: Samuel Just <sam.just@inktank.com>

mon: note that monmap may be reencoded later

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

mon: encoding new monmap using quorum feature set

It is probably unlikely that someone will expand the mon cluster with a
mixed feature set, but we know the quorum features here, so we should use
them.

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

mon: conditionally encode mon features for remote mon

The only time we encode these is when forwarding messages.  Encoding using
the destination's feature set.

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

mon: conditionally encode PGMap[::Incremental] with quorum features

This allows a mon cluster to transition to the new encoding during a
rolling upgrade.

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

mon: conditionally encode auth incremental with quorum feature bits

If the quorum does not yet all have the MONENC feature, stick to the old
encoding.

It might be more polite to require a super-quorum before switching over,
and take note so that thereafter we can stick to the new encoding, but
that has more moving parts and I'm not sure it's worth the complexity.

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

mon: track intersection of quorum member features

When we form a quorum, also note the intersection of the quorum members'
feature bits.  This will inform decisions about what encodings we use.

This is an imperfect strategy because the quorum may change, and we may
have a mon with old code join in and not understand what is going on.
However, it does ensure that a majority of the members run new code, so in
the absence of other failures we can make progress.

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

mon: conditionally encode old monmap when peer lacks feature

This allows a rolling upgrade from 0.47.2 to 0.48.

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

OSD,PG,ObjectStore: handle messages with old hobject_t encoding

Messages that embed an hobject_t need to have the pool field fixed
on messages from old peers.

Signed-off-by: Samuel Just <sam.just@inktank.com>

logrotate: reload all upstart instances

upstart doesn't let you wildcard all instances of a given job, so we
slog through initctl list output, and reload any running daemons.

Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Tommi Virtanen <tv@inktank.com>

Merge remote-tracking branch 'gh/stable' into next

v0.47.3

filestore: disable 'filestore fiemap' by default

We've seen this failing on both btrfs (Guido) and XFS (Oliver).  This works
around #2535.

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

OSD: clear_temp: split delete into many transactions

Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>

rgw: set s->header_ended before flushing formatter

otherwise we don't account the formatter in s->bytes_sent.

Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>

rgw: log user and not bucket owner for service operations

For operations that are done on the service (e.g., list buckets)
we need to log the user that did the operation, and not the bucket
owner.

Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>

rgw: initalize s->enable_usage_log

Missing initialization, we ended up not logging every operation.

Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>

osd: use derr (instead of cerr) for convertfs

This will appear in the log *and* stderr (if we're running in the
foreground).

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

osd: close stderr on daemonize

This spams stderr in an ugly way.  Users should look at the logs.

In particular, filestore upgrades spam the console, which is unpleasant.

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

PG: improve find_best_info

07f853db3982e68b952a337cf91cbf7ec0709de9 is actually too conservative,
it suffices to find any info with a last_update of at least the least
last_update from the last period to go active.  An info from a previous
interval is acceptable if the last interval never reported a commited
operation and thus still has the same last_update.

Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>

PG: reg_last_pg_scrub on pg resurrection

This may solve the unreg_last_pg_scrub assert.

see #2453.

Signed-off-by: Samuel Just <sam.just@inktank.com>

ceph_osd: move auto-upgrade to after fork

Signed-off-by: Samuel Just <sam.just@inktank.com>

filestore: make disk format upgrade warning less scary, more informative

Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Sam Just <sam.just@inktank.com>

mon: include quorum in ceph status

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