radosgw-admin: fix subuser modify

Shouldn't check for empty access key when modifying swift user, also
set correct fields when updating swift keys.

Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
rgw: subuser creation can be idempotent

No real reason to check for existing subuser before (re)creating it.

Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
radosgw-admin: don't always generate access key for subusers

Only generate key for subuser if one was not specified for it, and only
when creating a subuser.

Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
client: try shrinking kernel inode cache when trimming session caps

Notify kernel to invalidate top level directory entries. As a side
effect, the kernel inode cache get shrinked.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
client: pin parent dentry of inode who has ll_ref > 0

This prevents Client:trim_dentry() from unlinking parent dentry of
directory inode referenced by fuse kernel module.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
erasure-code: thread-safe initialization of gf-complete

Instead of relying on an implicit initialization happening during
encoding/decoding with galois.c:galois_init_default_field, call
gf.c:gf_init_easy for each w values when the plugin is loaded.

Loading the plugin is protected against race conditions by a lock.

It does not cover all possible uses of gf-complete but it is enough for
the ceph jerasure plugin.

http://tracker.ceph.com/issues/7914 fixes #7914

Signed-off-by: Loic Dachary <loic@dachary.org>
mds: fix shared_ptr MDRequest bugs

The main change is use shared_ptr instead of weak_ptr to define
active request map. The reason is that slave request needs to be
preserved until master explicitly finishes it.

Fixes: #8026
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
osd: make misdirected checks explicit about replicas, flags

Only allow read ops to target replicas if the necessary op flags are set.
The previous checks were very sloppy.

Fixes: #8031
Signed-off-by: Sage Weil <sage@inktank.com>
osd: drop previous interval ops even if primary happens to be the same

If we have two consecutive intervals with the same primary, the client
will not resend the op and the same_primary_since epoch will not change,
and all is well.

If, however, we have 3 intervals, and the primary changes away and then
back to a particular OSD, the OSD will currently still process the old
request (assuming the timing works out) because it is currently the
primary.  This is unnecessary because the client will resend the request.
It may even introduce a hard-to-hit ordering problem since whether or not
the OSD processes the message becomes dependent on how many subsequent
maps it has consumed when the request is processed.

Instead, simplify the minor tangle of helpers by making a single simple
check that discards requests from before same_primary_since.  We can then
avoid using the same_for_*() helpers and drop the check from
handle_misdireted_op(), which is also nice because the name is now accurate
(it *only* deals with ops that are in fact misdirected, not just slow to
arrive).

Signed-off-by: Sage Weil <sage@inktank.com>
osd: drop unused same_for_*() helpers

These were all identical and mostly served to obscure the actual logic,
which is now captured by can_discard_op() and the matching Objecter
code on the client side.

Signed-off-by: Sage Weil <sage@inktank.com>
Merge pull request #1621 from dachary/wip-7914

erasure-code: thread-safe initialization of gf-complete

This looks like a good interim solution until gf-complete exposes a simpler init function
that hides this.

Reviewed-by: Sage Weil <sage@inktank.com>
Merge pull request #1623 from ceph/wip-8026

mds: fix shared_ptr MDRequest bugs

Reviewed-by: Greg Farnum <greg@inktank.com>
vstart.sh: make crush location match up with what init-ceph does

This makes is to that ./init-ceph restart osd.0 won't modify the CRUSH
tree.  And in any case, the localhost/localrack thing we were doing before
was pretty useless.

Signed-off-by: Sage Weil <sage@inktank.com>
os/FileStore: reset journal state on umount

We observed a sequence like:

 - replay journal
   - sets JournalingObjectStore applied_op_seq
 - umount
 - mount
   - initiate commit with prevous applied_op_seq
 - replay journal
   - commit finishes
   - on replay commit, we fail assert op > committed_seq

Although strictly speaking the assert failure is harmless here, in general
we should not let state leak through from a previous mount into this
mount or else assertions are in general more difficult to reason about.

Fixes: #8019
Signed-off-by: Sage Weil <sage@inktank.com>
osd/PG: set CREATING pg state bit until we peer for the first time

We send PG state updates to the monitor while creating a PG before the
actual creation and been finalized and persisted.  Because those updates
do not include the CREATING bit, the mon will remove the pgid from it's
creating set.  If the OSD(s) crash before persisting that PG creation, the
PG will never get created.

Fix this by leaving the CREATING bit set on the primary as long as
last_epoch_started==0.  That is, until we successfully peer for the very
first time.  Only then do we clear the bit and tell the monitor it's duty
is complete.

Fixes: #8001
Signed-off-by: Sage Weil <sage@inktank.com>
Merge pull request #1625 from ceph/wip-8019

osd: fix journal umount/mount weirdness

Reviewed-by: Samuel Just <sam.just@inktank.com>
ceph.spec: update ceph description

Fixes: #5835
Signed-off-by: Sage Weil <sage@inktank.com>
debian: update ceph description

Fixes: #5835
Signed-off-by: Sage Weil <sage@inktank.com>
remove mkcephfs

Fixes: #7552
Signed-off-by: Sage Weil <sage@inktank.com>
Merge pull request #1628 from ceph/wip-5835

update package descriptions

Reviewed-by: Josh Durgin <josh.durgin@inktank.com>