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>
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>
mon/PGMonitor: use poolname reference instead of get it in osdmap
Reviewed-by: Joao Eduardo Luis <joao@suse.de>
Reviewed-by: Kefu Chai <kchai@redhat.com>
Makes it easier to identify the command as being related with the
monitor instead of cluster-wide.
This entails adding an exception to module 'mon' in order to have this
command handled by the Monitor class instead of MonmapMonitor (which is
the one traditionally handling 'mon' module commands).
Fixes: #11545
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Makes it easier to identify the command as being related with the
monitor instead of cluster-wide.
This entails adding an exception to module 'mon' in order to have this
command handled by the Monitor class instead of MonmapMonitor (which is
the one traditionally handling 'mon' module commands).
Fixes: #11545
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Makes it easier to identify the command as being related with the
monitor instead of cluster-wide.
This entails adding an exception to module 'mon' in order to have this
command handled by the Monitor class instead of MonmapMonitor (which is
the one traditionally handling 'mon' module commands).
Fixes: #11545
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Otherwise it's virtually impossible to change a command's help string
without triggering a mismatch with the leader's command set.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Instead of passing '0' for commands without flags, pass FLAG_NONE
instead. It's prettier and more obvious -- and it only costs 64 bits.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
This allows us to do nifty stuff like 'FLAG(foo) | FLAG(bar)' and expand
it to (MonCommand::FLAG_foo | MonCommand::FLAG_bar), instead of being
bound by a single flag on macro expansion.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Corrects minor Automake errors which prevented Ceph from building
when configure was invoked from a different directory than
the toplevel source directory.
Signed-off-by: Krzysztof Kosiński <krzysztof.kosinski@intel.com>
