tests: test/cephtool-test-mon.sh uses 7202 7203 and 7204
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.
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.
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.
mon: Monitor: drop PaxoServiceMessage reply functions
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 :)
mon: MonOpRequest: send_reply() belongs in the Monitor class
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.
mon: PaxosService: use wait_for_.*_ctx() in absence of an op
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.
mon: PaxosService: have wait_for_* functions requiring an op
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.
mon: PGMonitor: implement C_MonOp on op-related callback contexts
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.
mon: OSDMonitor: implement C_MonOp on op-related callback contexts
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.
mon: LogMonitor: implements C_MonOp on op-related callback contexts
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.
mon: PaxosService: implement C_MonOp on op-related callback contexts
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.
mon: Monitor: implement C_MonOp on op-related callback contexts
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.
mon: MonOpRequest: have the monitor dealing with operations
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>
mon: PaxosService: call post_refresh() instead of post_paxos_update()
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>
mon: Monitor: use 'ceph mon sync force' instead of 'ceph sync force'
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>
mon: Monitor: use 'ceph mon scrub' instead of 'ceph scrub'
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>
mon: Monitor: use 'ceph mon compact' instead of 'ceph compact'
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>
mon: MonCommands: accept FLAG(f) instead of 'f' in command sig
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.
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>
time_t is more a arithmetic type. and it's not portable. it's always
defined as "long int" by libc. and we have no encode(int, bl), which
is expected. so a safe way is to use int64_t for presenting the mtime
returned from the stat() call.
Ken Dreyer [Tue, 23 Jun 2015 19:41:53 +0000 (13:41 -0600)]
packaging: RGW depends on /etc/mime.types
If the mimecap RPM or mime-support DEB is not installed, then the
/etc/mime.types file is not present on the system. RGW attempts to read
this file during startup, and if the file is not present, RGW logs an
error:
ext_mime_map_init(): failed to open file=/etc/mime.types ret=-2
Make the radosgw package depend on the mailcap/mime-support packages so
that /etc/mime.types is always available on RGW systems.
ceph.in: print more detailed error message for 'tell' command
* we do not allow user specify a certain daemon when starting an
interactive session. the existing error message could lead to
some confusion. so put more details in it.
projects / ceph.git / log