Open Stack

from_environ was mine, it's reasonably new and at the time i was blocked
upon getting a release before pushing it out to services. Since then i've
been distracted with other things. The intent at the time was exactly this
to standardize the values on the context object, though in my case i was
particularly interested with how we could handle authentication plugins.

The problems i hit were specifically around how we could seperate values
that were relevant to things like policy from values that were relevant for
RPC etc rather that the big to_dict that is used for everything at the
moment.

There were a number of problems with this, however nothing that would
prevent more standardization of the base attributes and using from_environ
now.


On 6 April 2016 at 07:39, Ronald Bradford <me at ronaldbradford.com> wrote:

> 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
>>
>
>
> __________________________________________________________________________
> 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/20160406/4da60389/attachment.html>