Open Stack

Sean,

I cannot speak to historically why there were not there, but I am working
through the app-agnostic-logging-parameters blueprint [1] right now and
it's very related to this.  As part of this work I would be reviewing
attributes that are more commonly used in subclassed context objects for
inclusion into the base oslo.context class, a step before a more kwargs
init() approach that many subclassed context object utilize now.

I am also proposing the standardization of context arguments [2]
(specifically ids), and names are not mentioned but I would like to follow
the proposed convention.

However, as you point out in the middleware [3], if the information is
already available I see no reason not to facilite the base oslo.context
class to consume this for subsequent use by logging.  FYI the
get_logging_values() work in [4] is specially to add logging only values
and this can be the first use case.

While devstack uses these logging format string options, the defaults
(which I presume are operator centric do not).  One of my goals of the
Austin Ops summit it to get to talk with actual operators and find out what
is really in use.   Regardless, the capacity to choose should be available
when possible if the information is already identified without subsequent
lookup.


Ronald


[1]
https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters
[2] https://review.openstack.org/#/c/290907/
[3]
http://docs.openstack.org/developer/keystonemiddleware/api/keystonemiddleware.auth_token.html#what-auth-token-adds-to-the-request-for-use-by-the-openstack-service
[4] https://review.openstack.org/#/c/274186/





On Tue, Apr 5, 2016 at 2:31 PM, Sean Dague <sean at dague.net> wrote:

> I was trying to clean up the divergent logging definitions in devstack
> as part of scrubbing out 'tenant' references -
> https://review.openstack.org/#/c/301801/ and in doing so stumbled over
> the fact that the extremely useful project_name and user_name fields are
> not in base oslo.context.
>
>
> https://github.com/openstack/oslo.context/blob/c63a359094907bc50cc5e1be716508ddee825dfa/oslo_context/context.py#L148-L159
>
> These are always available to be set -
>
> http://docs.openstack.org/developer/keystonemiddleware/api/keystonemiddleware.auth_token.html#what-auth-token-adds-to-the-request-for-use-by-the-openstack-service
>
> And they are extremely valuable when a human is looking at logs, as you
> actually can remember names when looking at various services to cross
> reference things. Nova has a custom context that sets these things -
>
> https://github.com/openstack/nova/blob/d57a4e8be9147bd79be12d3f5adccc9289a375b6/nova/api/auth.py#L114-L115
>
> I would really like these to be available in all services using
> oslo.context.
>
> So the question is, were these not implemented on purpose? Is the
> opposition to putting them into oslo.context?
>
> Please let me know before I start going down this path.
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160405/c8065e32/attachment.html>