doc: Created a new User Management doc to replace authentication.

Signed-off-by: John Wilkins <john.wilkins@inktank.com>
doc: Put architectural details of authentication in to architecture doc.

Signed-off-by: John Wilkins <john.wilkins@inktank.com>
doc: Restructured auth configuration reference.

Signed-off-by: John Wilkins <john.wilkins@inktank.com>
doc: Removed auth intro and auth docs and added user management to index.

Signed-off-by: John Wilkins <john.wilkins@inktank.com>
doc: Removed cephx guide. Replaced by user management.

Signed-off-by: John Wilkins <john.wilkins@inktank.com>
doc: Removed cephx intro. Moved details to user management, config, and architecture.

Signed-off-by: John Wilkins <john.wilkins@inktank.com>
doc: Added user management link to quick start.

Signed-off-by: John Wilkins <john.wilkins@inktank.com>
doc: Added a few comments and links to other relevant docs.

Signed-off-by: John Wilkins <john.wilkins@inktank.com>
qa/workunits/hadoop/wordcount: remove bogus rm -r

Signed-off-by: Sage Weil <sage@redhat.com>
doc: Minor changes.

Removed arch-related comments.
Added links to relevant docs.
Moved limitations to user management.

Signed-off-by: John Wilkins <john.wilkins@inktank.com>
doc: Added links. Clarified namespace comments. Added limitations.

Signed-off-by: John Wilkins <john.wilkins@inktank.com>
mon/OSDMonitor: make reweight_by_* output less misleading

Sometimes we increase weights.  State simply which OSDs are reweighted
(not overloaded).

Signed-off-by: Sage Weil <sage@redhat.com>
common: LogEntry: change field name from 'type' to 'prio' (aka priority)

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
common: LogEntry: add clog_type_to_string()

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
common: LogEntry: add 'channel' field

We now introduce the concept of 'channel', analogous to syslog
facilities, for log entries.  This will, shortly, allow a LogClient
to send messages to more than just the default syslog facility and log
file, also allowing multiple LogClients and having a way to associate
a LogEntry with its rightful owner.

We also add the same field to the MLogAck message so that a LogClient
waiting on a given ack is able to recognize the MLogAck as its own.

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
common: LogEntry: refactor how we output to syslog

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
common: LogClient: delegate message reference release to caller

Caller decides whether to release the message's reference.  It may want
to use the same message on another LogClient, if we decide not to handle
it.

Currently we always handle the message and thus always return true.  This
will not be as such later in the patch series.

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
common: str_map: add helper methods to get values from maps

Both methods obtain values for keys from a given map.  Main distinction
is that one method will return a default value if key is not present and
if the default value is specified (i.e., not NULL), while the other
method will return the value of a fallback key if the key is not
present.

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
common: str_map: have 'get_str_map' only handling plain-text

'get_str_map()' used to handle both JSON and plain-text.  In fact it
would try parsing the map as JSON on a first try and then fallback to
plain-text if it failed.  Altough useful this would pose a big issue
when we attempted to parse some values, tha we knew to be plain-text,
that had some meaning in JSON -- e.g., 'false' or 'true'.  In such case
the JSON parser would spit out an error, stating it had been able to
parse the JSON but didn't expected the type, which in fairness is
acceptable.

In its stead we now have two functions: 'get_str_map()' will only handle
plain-text, whereas 'get_json_str_map()' will keep the previous
behavior, attempting to parse a JSON string and falling back to
'get_str_map()' should it fail.

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
common: LogClient: allow specifying facility for LogClient

Instead of allowing only one LogClient, we will now allow any daemon to
have any number of LogClients.  They may either all log to the default
facility and level, or they may see their facility and level specified
upon creation (via a new constructor).

This patch also changes 'handle_log_ack' in such a way that the LogClient
will handle all acks with bearing the LogClient's facility, or will
otherwise simply ignore them.  The function will return true whenever the
message has been handled or false if that was not the case.  It will fall
on the caller the responsibility of deciding whether the message will be
passed to other LogClients or not, and when it is to be release.

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>