Open Stack

I have created a version that use constructor arguments. [5]
I will review in more detail across projects the use of keystone middleware
to see if we can utilize a constructor environment attribute to simply
constructor usage.

[5] https://review.openstack.org/301918

Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:    @RonaldBradford <http://twitter.com/ronaldbradford>
Skype:     RonaldBradford
GTalk:     Ronald.Bradford
IRC:         rbradfor


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

> 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
>
> __________________________________________________________________________
> 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/2b75afa5/attachment.html>