Open Stack

Cool. Great.

In looking at this code a bit more I think we're missing out on some
commonality by the fact that this nice bit of common parsing -
https://github.com/openstack/oslo.context/blob/c63a359094907bc50cc5e1be716508ddee825dfa/oslo_context/context.py#L138-L161
is actually hidden behind a factory pattern, and not used by anyone in
OpenStack -
http://codesearch.openstack.org/?q=from_environ&i=nope&files=&repos=

If instead of standardizing the args to the context constructor, we
could remove a bunch of them and extract that data from a passed
environment during the constructor that should remove a bunch of parsing
code in every project. It would also mean that we could easily add
things like project_name and user_name in, and they would be available
to all consumers.

	-Sean

On 04/05/2016 03:39 PM, Ronald Bradford wrote:
> 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
> <mailto: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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> __________________________________________________________________________
> 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
> 


-- 
Sean Dague
http://dague.net