[openstack-dev] [oslo] Removing Nova specifics from oslo.log

Doug Hellmann doug at doughellmann.com
Wed Apr 13 19:55:02 UTC 2016

Excerpts from Sean Dague's message of 2016-04-11 10:16:23 -0400:
> On 04/11/2016 10:08 AM, Ed Leafe wrote:
> > On 04/11/2016 08:38 AM, Julien Danjou wrote:
> > 
> >> There's a lot of assumption in oslo.log about Nova, such as talking
> >> about "instance" and "context" in a lot of the code by default. There's
> >> even a dependency on oslo.context. >.<
> >>
> >> That's being an issue for projects not being Nova, where we end up
> >> having configuration options talking about "instances" and with default
> >> values referring to that.
> >> I'm at least taking that as being a serious UX issue for telemetry
> >> projects.
> >>
> >> I'd love to sanitize that library a bit. So, is this an option, or would
> >> I be better off starting something new?
> > 
> > The nova team spent a lot of time in Mitaka starting to clean up the
> > config options that were scattered all over the codebase, and improve
> > the help text for each of them so that you didn't need to grep the
> > source code to find out what they did.
> > 
> > I could see a similar effort for oslo.log (and maybe other oslo
> > projects), and I would be happy to help out.
> This isn't so much about scattered options, oslo.log options are all in
> one place already, it's about the application specific ones that are
> embedded.
> I agree that "instance" being embedded all the way back to oslo.log is
> weird. Ideally we'd have something like "resource" that if specified
> would be the primary resource the request was acting on. Or could even
> just build some custom loggers Nova side to inject the instance when we
> have it.
> I'm not sure why oslo.context is an issue though. That's mostly about
> putting in the common information about the identity of the requester
> into the stream.

The context is also the place, frequently, where we know the id of the
resource on which action is being taken.


More information about the OpenStack-dev mailing list