config: always complain about config parse errors

Complain about config parsing errors even when it is the default
config file.

We may also want to fail instead of continuing, but that is a separate
issue.

Signed-off-by: Sage Weil <sage@inktank.com>
config: do not always print config file missing errors

Do not generate errors each time we fail to open a config file; only
generate one at the end if a search path was specified and none were
usable, right before we (already) exit.  This avoids spamming stderr
about each path we tried in the search list before we found a good one.

Signed-off-by: Sage Weil <sage@inktank.com>
objecter: don't use new tid when retrying notifies

Watches update the on-disk state in the OSD, and aren't idempotent,
so refreshing them must be treated as a separate transaction by the OSD.
Notifies are just in-memory state, and resending them will result in
acceptable behavior:

- if it's the same osd, the resent op will be recognized as a duplicate
- if it's a different osd, a new notify will be triggered since the new osd
  can't tell whether the original notify was received by any watchers

Using a new tid for each resend can cause some unecessary extra work,
as the first case turns into the second.

Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Merge remote-tracking branch 'gh/wip-conf' into next

Reviewed-by: Greg Farnu <greg@inktank.com>
mds: shutdown cleanly if can't authenticate

Fixes: #3590
This was triggered when tried to run mds with cephx enabled
against a mon without cephx support. We didn't handle the
returned error at all, so this one fixes it. It also makes
sure that we don't continue initialization until rotating
keys are in place (as the osd does).

Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
st_rados_watch: tolerate extra notifies

With retries, it's possible for notifies to be received more than once
when they are resent to different OSDs, since the OSDs only track them
in memory.

Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
os/JournalingObjectStore: un-break op quiescing during journal replay

Commit d9dce4e9273adb4279519d65a0d8bfdfecb5c516 broke journal replay
because the commit thread may try to do a commit, and the ops are not
being applied via the normal work queue.  Add back in a simpler form of the
old op quiescing (simpler because there is a single thread doing the
replay).

Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Samuel Just <sam.just@inktank.com>
Merge remote branch 'origin/wip-double-notify' into next

Reviewed-by: Sage Weil <sage.weil@inktank.com>
docs: fix spacing in radosgw config-ref

Needed to add an extra empty line between header and properties.

Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
PG,ReplicatedPG: move write_blocked_by_scrub logic into a helper

Signed-off-by: Samuel Just <sam.just@inktank.com>
PG,ReplicatedPG: handle_watch_timeout must not write during scrub/degraded

Currently, handle_watch_timeout will gladly write to an object while
that object is degraded or is being scrubbed.  Now, we queue a
callback to be called on scrub completion or finish_degraded_object
to recall handle_watch_timeout.  The callback mechanism assumes that
the registered callbacks assume they will be called with the pg
lock -- and no other locks -- already held.

Signed-off-by: Samuel Just <sam.just@inktank.com>
DNM: testing