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. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev