Open Stack

On 23/01/15 19:47, Mike Bayer wrote:
> 
> 
> Doug Hellmann <doug at doughellmann.com> wrote:
> 
>>
>>
>> On Fri, Jan 23, 2015, at 12:49 PM, Mike Bayer wrote:
>>> Mike Bayer <mbayer at redhat.com> wrote:
>>>
>>>> Ihar Hrachyshka <ihrachys at redhat.com> wrote:
>>>>
>>>>> On 01/23/2015 05:38 PM, Mike Bayer wrote:
>>>>>> Doug Hellmann <doug at doughellmann.com> wrote:
>>>>>>
>>>>>>> We put the new base class for RequestContext in its own library because
>>>>>>> both the logging and messaging code wanted to influence it's API. Would
>>>>>>> it make sense to do this database setup there, too?
>>>>>> whoa, where’s that? is this an oslo-wide RequestContext class ? that would
>>>>>> solve everything b.c. right now every project seems to implement
>>>>>> RequestContext themselves.
>>>
>>>
>>> so Doug -
>>>
>>> How does this “influence of API” occur, would oslo.db import
>>> oslo_context.context and patch onto RequestContext at that point? Or the
>>> other way around? Or… ?
>>
>> No, it's a social thing. I didn't want dependencies between
>> oslo.messaging and oslo.log, but the API of the context needs to support
>> use cases in both places.
>>
>> Your case might be different, in that we might need to actually have
>> oslo.context depend on oslo.db in order to call some setup code. We'll
>> have to think about whether that makes sense and what other dependencies
>> it might introduce between the existing users of oslo.context.
> 
> hey Doug -
> 
> for the moment, I have oslo_db.sqlalchemy.enginefacade applying its descriptors at import time onto oslo_context:
> 
> https://review.openstack.org/#/c/138215/30/oslo_db/sqlalchemy/enginefacade.py
> 
> https://review.openstack.org/gitweb?p=openstack/oslo.db.git;a=blob;f=oslo_db/sqlalchemy/enginefacade.py;h=3f76678a6c9788f62288c8fa5ef520db8dff2c0a;hb=bc33d20dc6db2f8e5f8cb02b4eb5f97d24dafb7a#l692
> 
> https://review.openstack.org/gitweb?p=openstack/oslo.db.git;a=blob;f=oslo_db/sqlalchemy/enginefacade.py;h=3f76678a6c9788f62288c8fa5ef520db8dff2c0a;hb=bc33d20dc6db2f8e5f8cb02b4eb5f97d24dafb7a#l498

May I suggest that we decouple these changes by doing both? Oslo's
RequestContext object can have the enginefacade decorator applied to it,
so any project which uses it doesn't have to apply it themselves.
Meanwhile, the decorator remains part of the public api for projects not
using the oslo RequestContext.

I suggest that we'll probably stay with a decorator within oslo, anyway.
It doesn't lend itself well to a Mixin, as we need a reference to a
specific _TransactionContextManager, and moving code directly into
RequestContext would be a very invasive coupling.

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490