Open Stack

On 12 Apr 2016 12:19 AM, "Sean Dague" <sean at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160412/5e3de2be/attachment.html>