Open Stack

Excerpts from Gregory Haynes's message of 2014-12-04 15:20:53 -0800:
> Hello TripleOers,
> 
> I got a patch together to move us off of our upstart exec <service> |
> logger -t <service> hack [1] and this got me wondering - why aren't we
> using the python logging.conf supported by most OpenStack projects [2]
> to write out logs to files in our desired location? 
> 
> This is highly desirable for a couple reasons:
> 
> * Less complexity / more straightforward. Basically we wouldn't have to
> run rsyslog or similar and have app config to talk to syslog then syslog
> config to put our logs where we want. We also don't have to battle with
> upstart + rsyslog vs systemd-journald differences and maintain two sets
> of configuration.
> 

+1 for less complexity and for just using the normal OS logging
facilities that exist and are quite efficient.

> * We get actual control over formatting. This is a double edged sword in
> that AFAICT you *have* to control formatting if you're using a
> logging.conf with a custom log handler. This means it would be a bit of
> a divergence from our "use the defaults" policy but there are some
> logging formats in the OpenStack docs [3] named "normal", maybe this
> could be acceptable? The big win here is we can avoid issues like having
> duplicate timestamps [4] (this issue still exists on Ubuntu, at least)
> without having to do two sets of configuration, one for upstart +
> rsyslog, one for systemd.
> 

This thread might need to get an [all] tag, and we might need to ask the
question "why isn't syslog the default?". I don't have a good answer for
that, so I think we might want to consider doing it, but I especially
would like to hear from operators how many of them actually log things
to syslog vs. on disk or something else.

> * This makes setting custom logging configuration a lot more feasible
> for operators. As-is, if an operator wants to forward logs to an
> existing central log server we dont really have a good way for them to
> do this. We also have a requirement that we can come up with a way to
> expose the rsyslog/journald config options needed to do this to
> operators. If we are using logging.conf we can just use our existing
> passthrough-config system to let operators simply write out custom
> logging.conf files which are already documented by OpenStack.

As usual, the parameters we have should just be things that we want to
ask users about on nearly every deployment. So I concur that passthrough
is the way to go, since it will only be for those who don't want to use
syslog for logging.