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>
We drop the lock when invoking the callback, which means the directory
we're looking at might get dentries trimmed out of memory. Make sure that
hasn't happened after we get the lock back. If it *has* happened, fall back
to requesting the directory contents from the MDS. Update the dirp location
pointers after each entry to facilitate this.
Because this requires we update the dirp->at_cache_name value on every loop,
we rework the updating scheme a bit: to dereference the dn->name before
unlocking, so we know it's filled in; and since we update it on every loop
we don't need to refer to the previous dentry explicitly like we did before.
This should also handle racing file deletes: we get back a trace on
the removed dentry and that will clear the COMPLETE|ORDERED flags.
Fixes#12297
Signed-off-by: Greg Farnum <gfarnum@redhat.com>
We want to fix the following scenario:
* an erasure code plugin (or another part of the code) creates a
ruleset
* the ruleset crashes during mapping (for whatever reason)
* ceph osd pool create uses the bugous ruleset
* the monitors try to do mapping a crash
Having a bugous ruleset in the crush map is very difficult prevent. The
catastrophic event of using it with a newly created pool can however be
prevented by calling the CrushTester just before creating the pool and
after all implicit or explicit crush ruleset creation happened.
http://tracker.ceph.com/issues/11814Fixes: #11814
Signed-off-by: Loic Dachary <ldachary@redhat.com>
Deal with op requests throughout the monitor state machine, instead of
Messages. These op requests implement TrackedOp, which will be
trackable by the monitor via a OpTracker. This will allow us to follow
the operation's life cycle, for the duration of any given operation.
Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
Whenever the monitor finishes committing a proposal, we call
Monitor::refresh_from_paxos() to nudge the services to refresh. Once
all services have refreshed, we would then call each services
post_paxos_update().
However, due to an unfortunate, non-critical bug, some services (mainly
the LogMonitor) could have messages pending in their
'waiting_for_finished_proposal' callback queue [1], and we need to nudge
those callbacks.
This patch adds a new step during the refresh phase: instead of calling
directly the service's post_paxos_update(), we introduce a
PaxosService::post_refresh() which will call the services
post_paxos_update() function first and then nudge those callbacks when
appropriate.
[1] - Given the monitor will send MLog messages to itself, and given the
service is not readable before its initial state is proposed and
committed, some of the initial MLog's would be stuck waiting for the
proposal to finish. However, by design, we only nudge those message's
callbacks when an election finishes or, if the leader, when the proposal
finishes. On peons, however, we would only nudge those callbacks if an
election happened to be triggered, hence the need for an alternate path
to retry any message waiting for the initial proposal to finish.
Fixes: #11470
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
'ceph mon_metadata' was added still during this dev cycle, so there is
no need to deprecate it first.
Fixes: #11545
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
