<div dir="ltr">I have created a version that use constructor arguments. [5]<div>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.<br><div><br></div><div>[5] <a href="https://review.openstack.org/301918">https://review.openstack.org/301918</a><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div><div style="font-family:arial;font-size:small">Ronald Bradford</div><div style="font-family:arial;font-size:small"><br></div><span style="color:rgb(102,102,102)">Web Site: </span><a style="color:rgb(102,102,102)" href="http://ronaldbradford.com/" target="_blank">http://ronaldbradford.com</a><br style="color:rgb(102,102,102)">














































































































































































































































































































<span style="color:rgb(102,102,102)">LinkedIn:  </span><a style="color:rgb(102,102,102)" href="http://www.linkedin.com/in/ronaldbradford" target="_blank">http://www.linkedin.com/in/ronaldbradford</a><br><span style="color:rgb(102,102,102)">Twitter:    </span><a style="color:rgb(102,102,102)" href="http://twitter.com/ronaldbradford" target="_blank">@RonaldBradford</a><br>





















<span style="color:rgb(102,102,102)">Skype:     RonaldBradford</span><div><span style="color:rgb(102,102,102)">GTalk:     Ronald.Bradford<br></span><div><span style="color:rgb(102,102,102)">IRC:         rbradfor<br></span><br></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Apr 5, 2016 at 3:49 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Cool. Great.<br>
<br>
In looking at this code a bit more I think we're missing out on some<br>
commonality by the fact that this nice bit of common parsing -<br>
<a href="https://github.com/openstack/oslo.context/blob/c63a359094907bc50cc5e1be716508ddee825dfa/oslo_context/context.py#L138-L161" rel="noreferrer" target="_blank">https://github.com/openstack/oslo.context/blob/c63a359094907bc50cc5e1be716508ddee825dfa/oslo_context/context.py#L138-L161</a><br>
is actually hidden behind a factory pattern, and not used by anyone in<br>
OpenStack -<br>
<a href="http://codesearch.openstack.org/?q=from_environ&i=nope&files=&repos=" rel="noreferrer" target="_blank">http://codesearch.openstack.org/?q=from_environ&i=nope&files=&repos=</a><br>
<br>
If instead of standardizing the args to the context constructor, we<br>
could remove a bunch of them and extract that data from a passed<br>
environment during the constructor that should remove a bunch of parsing<br>
code in every project. It would also mean that we could easily add<br>
things like project_name and user_name in, and they would be available<br>
to all consumers.<br>
<br>
        -Sean<br>
<div><div class="h5"><br>
On 04/05/2016 03:39 PM, Ronald Bradford wrote:<br>
> Sean,<br>
><br>
> I cannot speak to historically why there were not there, but I am<br>
> working through the app-agnostic-logging-parameters blueprint [1] right<br>
> now and it's very related to this.  As part of this work I would be<br>
> reviewing attributes that are more commonly used in subclassed context<br>
> objects for inclusion into the base oslo.context class, a step before a<br>
> more kwargs init() approach that many subclassed context object utilize now.<br>
><br>
> I am also proposing the standardization of context arguments [2]<br>
> (specifically ids), and names are not mentioned but I would like to<br>
> follow the proposed convention.<br>
><br>
> However, as you point out in the middleware [3], if the information is<br>
> already available I see no reason not to facilite the base oslo.context<br>
> class to consume this for subsequent use by logging.  FYI the<br>
> get_logging_values() work in [4] is specially to add logging only values<br>
> and this can be the first use case.<br>
><br>
> While devstack uses these logging format string options, the defaults<br>
> (which I presume are operator centric do not).  One of my goals of the<br>
> Austin Ops summit it to get to talk with actual operators and find out<br>
> what is really in use.   Regardless, the capacity to choose should be<br>
> available when possible if the information is already identified without<br>
> subsequent lookup.<br>
><br>
><br>
> Ronald<br>
><br>
><br>
> [1] <a href="https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters</a><br>
> [2] <a href="https://review.openstack.org/#/c/290907/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/290907/</a><br>
> [3] <a href="http://docs.openstack.org/developer/keystonemiddleware/api/keystonemiddleware.auth_token.html#what-auth-token-adds-to-the-request-for-use-by-the-openstack-service" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/keystonemiddleware/api/keystonemiddleware.auth_token.html#what-auth-token-adds-to-the-request-for-use-by-the-openstack-service</a><br>
> [4] <a href="https://review.openstack.org/#/c/274186/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/274186/</a><br>
><br>
><br>
><br>
><br>
><br>
> On Tue, Apr 5, 2016 at 2:31 PM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a><br>
</div></div><div><div class="h5">> <mailto:<a href="mailto:sean@dague.net">sean@dague.net</a>>> wrote:<br>
><br>
>     I was trying to clean up the divergent logging definitions in devstack<br>
>     as part of scrubbing out 'tenant' references -<br>
>     <a href="https://review.openstack.org/#/c/301801/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/301801/</a> and in doing so stumbled over<br>
>     the fact that the extremely useful project_name and user_name fields are<br>
>     not in base oslo.context.<br>
><br>
>     <a href="https://github.com/openstack/oslo.context/blob/c63a359094907bc50cc5e1be716508ddee825dfa/oslo_context/context.py#L148-L159" rel="noreferrer" target="_blank">https://github.com/openstack/oslo.context/blob/c63a359094907bc50cc5e1be716508ddee825dfa/oslo_context/context.py#L148-L159</a><br>
><br>
>     These are always available to be set -<br>
>     <a href="http://docs.openstack.org/developer/keystonemiddleware/api/keystonemiddleware.auth_token.html#what-auth-token-adds-to-the-request-for-use-by-the-openstack-service" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/keystonemiddleware/api/keystonemiddleware.auth_token.html#what-auth-token-adds-to-the-request-for-use-by-the-openstack-service</a><br>
><br>
>     And they are extremely valuable when a human is looking at logs, as you<br>
>     actually can remember names when looking at various services to cross<br>
>     reference things. Nova has a custom context that sets these things -<br>
>     <a href="https://github.com/openstack/nova/blob/d57a4e8be9147bd79be12d3f5adccc9289a375b6/nova/api/auth.py#L114-L115" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/d57a4e8be9147bd79be12d3f5adccc9289a375b6/nova/api/auth.py#L114-L115</a><br>
><br>
>     I would really like these to be available in all services using<br>
>     oslo.context.<br>
><br>
>     So the question is, were these not implemented on purpose? Is the<br>
>     opposition to putting them into oslo.context?<br>
><br>
>     Please let me know before I start going down this path.<br>
><br>
>             -Sean<br>
><br>
>     --<br>
>     Sean Dague<br>
>     <a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
><br>
>     __________________________________________________________________________<br>
>     OpenStack Development Mailing List (not for usage questions)<br>
>     Unsubscribe:<br>
>     <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
</div></div>>     <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
>     <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<div class="HOEnZb"><div class="h5">><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>