gen_state_diagram.py: fix naming of global variables/constants

Signed-off-by: Danny Al-Gaaf <danny.al-gaaf@bisect.de>
gen_state_diagram.py: fix function name

Signed-off-by: Danny Al-Gaaf <danny.al-gaaf@bisect.de>
Merge branch 'wip-4748-b' into next

Reviewed-by: Greg Farnum <greg@inktank.com>
init-ceph: use remote config when starting daemons on remote nodes (-a)

If you use -a to start a remote daemon, assume the remote config is present
instead of pushing the local config.  This makes more sense and simplifies
things.

Note that this means that -a in concert with -c foo means that foo must
also be present on the remote node in the same path.  That, however, is a
use case that I don't particularly care about right now.  :)

Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Dan Mick <dan.mick@inktank.com>
doc/release-notes: add note about sysvinit script change

See cd7e52cc76878eed0f084f7b9a6cf7c792b716c6.

Signed-off-by: Sage Weil <sage@inktank.com>
Merge remote-tracking branch 'gh/next'
PendingReleaseNotes: these are now in the release-notes.rst

Signed-off-by: Sage Weil <sage@inktank.com>
radosgw: receiving unexpected error code while accessing an non-existing object by authorized not-owner user

This patch fixes a bug in radosgw swift compatibility code,
that is, if a not-owner but authorized user access a non-existing
object in a container, he wiil receive unexpected error code,
to repeat this bug, do the following steps,

1 User1 creates a container, and grants the read/write permission to user2

curl -X PUT -i -k -H "X-Auth-Token: $user1_token" $url/$container
curl -X POST -i -k -H "X-Auth-Token: $user1_token" -H "X-Container-Read:
$user2" -H "X-Container-Write: $user2" $url/$container

2 User2 queries the object 'obj' in the newly created container
by using HEAD instruction, note the container currently is empty

curl -X HEAD -i -k -H "X-Auth-Token: $user2_token" $url/$container/obj

3 The response received by user2 is '401 Authorization Required',
rather than the expected '404 Not Found', the details are as follows,

HTTP/1.1 401 Authorization Required
Date: Tue, 16 Apr 2013 01:52:49 GMT
Server: Apache/2.2.22 (Ubuntu)
Accept-Ranges: bytes
Content-Length: 12
Vary: Accept-Encoding

Signed-off-by: Yunchuan Wen <yunchuanwen@ubuntukylin.com>
Signed-off-by: Li Wang <liwang@ubuntukylin.com>
Reviewed-by: Yehuda Sadeh <yehuda@inktank.com>
Merge pull request #246 from ceph/wip-4793

#4793

Reviewed-by: Sage Weil <sage@inktank.com>
Merge pull request #239 from ceph/wip-4760

#4760

Second patch Reviewed-by: Sage Weil <sage@inktank.com>
mon: get own entity_inst_t via messenger, not monmap

There are intervals during bootstrap(*) during which we are part of the
monmap, but our name (mon->name) does not match the monmap's.  This means
that calling monmap->get_inst(mon->name) is not a safe way to get our own
entity_inst_t.

Instead, use messenger->get_myinst().  This includes our addr (obviously)
and an up-to-date entity_name_t, too: in bootstrap we adjust the messenger
name at the same time as mon->rank, based on the contents of the monmap.

monmap->get_inst(mon->rank) would work too.

* During mkfs, the monmap may have noname-foo instead of the name if it was
  generated from the mon_host lines or dns or whatever by
  MonMap::build_initial().  This was the case for #4811.

Fixes: #4811
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
PG: clear want_acting when we leave Primary

This is somewhat annoying actually.  Intuitively we want to
clear_primary_state when we leave primary, but when we restart
peering due to a change in prior set status, we can't afford
to forget most of our peering state.  want_acting, on the
other hand, should never persist across peering attempts.
In fact, in the future, want_acting should be pulled into
the Primary state structure.

Fixes: #3904
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Reviewed-by: David Zafman <david.zafman@inktank.com>
mon: do not forward other mon's requests to other mons

The request forwarding infrastructure is there for client requests.
However, we (ab)use it for mon's sending MLog messages: LogClient sends an
MLog message to itself, and that is either handled locally (if leader) or
forwarded to the leader.

If that races with an election, we were forwarding an MLog from another mon
to the leader.  This is not necessary; the original MLog sender will resend
the request on election_finish() to the latest leader.

The fix is to adjust forward_request_leader() to only forward messages from
a mon if that mon is itself.

This was reproduced while testing the fix for #4748.

Signed-off-by: Sage Weil <sage@inktank.com>
debian/rules: use multiline search to look for Build-Depends

When Build-Depends was split into multiple lines (in commit
8f5c665744e58d6d51a1e86de55c1399f51cc1c3), the grep for
libgoogle-perftools-dev broke.  Replace grep with perl for multiline
matching.

Fixes: #4818
Signed-off-by: Dan Mick <dan.mick@inktank.com>
client: don't embed cap releases in clientreplay

If the client is sending replay requests, avoid sending embedded caps,
since the mds already has the client's caps from the reconnect.
This matches the behavior of the kernel client.

Fixes #4742.
Signed-off-by: Sam Lang <sam.lang@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
client: re-fix cap releases

Encode cap releases if NOT replay.  <facepalm>  Thanks, Greg!

Signed-off-by: Sage Weil <sage@inktank.com>
debian/rules: use multiline search to look for Build-Depends

When Build-Depends was split into multiple lines (in commit
8f5c665744e58d6d51a1e86de55c1399f51cc1c3), the grep for
libgoogle-perftools-dev broke.  Replace grep with perl for multiline
matching.

Fixes: #4818
Signed-off-by: Dan Mick <dan.mick@inktank.com>
(cherry picked from commit 89692e099f20424a5effcefcd33df154ebc5de39)
osd: Fix logic in OSDMap::containing_subtree_is_down()

Check for up OSDs as we walk up the crushmap hierarchy

fixes: #4822

Signed-off-by: David Zafman <david.zafman@inktank.com>
mon: fix double-forwarding check

The PaxosServiceMessage fields are no longer filled in.  Use Session::proxy_con
instead.

Signed-off-by: Sage Weil <sage@inktank.com>
mon: mark PaxosServiceMessage forward fields deprecated

These are no longer used; we manage forward state explicitly via the
Monitor sessions instead.  Mark them deprecated so we don't accidentally
rely on them.  Also, fix the annoying "mon.-1" garbage debug output that
is confusing.

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