On 12 Apr 2016 12:19 AM, "Sean Dague" <s...@dague.net> wrote: > > 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.
Instance was put in there a long time ago, before Oslo existed. It was then just forklifted out blindly. I like the idea of changing to something like "resource" or even better "resources", but we do need to present this information in a structured way. We need to remember this was added because of specific concerns around operational usability of or logging. > 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. Michael
__________________________________________________________________________ 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
