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>
common: LogEntry: if 'channel' is empty on decode assign default

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
mon: Monitor: log every administrative action in an 'audit log'

Fixes: #7988

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
mon: Monitor: log administrative actions via admin socket

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
mon: Monitor: propagate return for functions called for admin socket

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
mon: Monitor: observe log client config changes

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
mon: Monitor's clog/audit_clog need to accessed as pointers

:1,$s/clog\./clog->/

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
mon: LogMonitor: write log messages on a per-channel basis

Instead of dumping everything to the same log file, let us this way
allow a user to specify per-channel log files, levels and syslog
facilities.

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
mon: LogMonitor: observe config changes

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
mon: LogMonitor: expand meta variables at time-of-call

Instead of expanding it when we updated config options, as that would be
nothing but trouble.

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

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
osd/mds/monc: Adjust for LogClient/LogChannel usage

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
test: common: test_config: whitelist '$channel' meta-variable

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