"rewrite" command will
- add a new osdmap version to update current osdmap held by OSDMonitor
- add a new paxos version, as a proposal it will
* rewrite all osdmap epochs from specified epoch to the last_committed
one with the specified crush map.
* add the new osdmap which is added just now
so the leader monitor can trigger a recovery process to apply the transaction
to all monitors in quorum, and hence bring them back to normal after being
injected with a faulty crushmap.
Fixes: #11815
Signed-off-by: Kefu Chai <kchai@redhat.com>
When running 3 mons, vstart uses ports starting from CEPH_PORT=7202 and
increments to 7203 for the second mon and 7204 for the third. Add a
comment showing the port number. The method for a test to figure out
which port is free is to grep for the port and if nothing matches, use
it. The grep will match 7204 and 7203 and 7202 from the comment and
reduce the chances of someone using 7203 because it was nowhere to be
found in the sources.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
Don't simply put() a reference if it has gone unclaimed without
get()'ing it first. This can cause nefarious consequences for those
users of MForward that do not expect this to happen.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
When we introduced the MonOpRequest in the monitor and moved pretty much
every single function receiving messages in their arguments to take op
requests, we basically lost the type safety that was guaranteed from
Monitor::dispatch().
This patch adds an op_type field to the op request, as an easy fix for
this now lacking safety.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
The services are now fully using MonOpRequest and should stay that way.
Drop PaxosService-specific reply functions as we want nothing to do with
them :)
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Op Requests should have no business replying to messages. Besides,
given the Monitor is currently the place to do this, because it is the
one with access to all things that may be required to validate state
(e.g., quorum features), permanently moving this code to the Monitor
class also avoid having duplicate/very similar code in two distinct
places.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
We are replying to operations, not messages, so use the appropriate
function to do so (and mark events).
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
The vast majority of cases use PaxosService's wait_for_{state}()
functions to wait on given {state} before waking up a given op-related
callback. E.g., to reply to a command once a proposal finishes.
However, there are a few cases[1] in which the callback waiting for the
state change does not map to an op.
To maintain compatibility, we were keeping the functions just taking a
callback and no op with the same name as those taking ops (because c++
is amazing that way), but we realized that developers could keep on
using these functions just as before, disregarding the fact that they
likely want to use the version taking the op. As such, this patch
changes the name of the function taking only the callback, such that it
is used solely when the developer really wants to take just the
callback.
[1] at time of this patch, only three calls were being made that would
use only a callback. Out of over one hundred calls using ops.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Basically, so we can mark the op accordinly; we'll leave context-only
functions to maintain compatibility with other users of these functions
that do not use them for op-related callbacks.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
These contexts deal with MonOpRequests, and we need to track their life
cycle; use C_MonOp to mark events when the callbacks are woken up for
some reason.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
These contexts deal with MonOpRequests, and we need to track their life
cycle; use C_MonOp to mark events when the callbacks are woken up for
some reason.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
These contexts deal with MonOpRequests, and we need to track their life
cycle; use C_MonOp to mark events when the callbacks are woken up for
some reason.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
These contexts deal with MonOpRequests, and we need to track their life
cycle; use C_MonOp to mark events when the callbacks are woken up for
some reason.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
These contexts deal with MonOpRequests, and we need to track their life
cycle; use C_MonOp to mark events when the callbacks are woken up for some
reason.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
To be used by monitor contexts relying on MonOpRequest, so that we can
easily track the lifespan of an event.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
