On Mon, Jan 26, 2015, at 08:55 AM, Matthew Booth wrote: > On 23/01/15 19:47, Mike Bayer wrote: > > > > > > Doug Hellmann <d...@doughellmann.com> wrote: > > > >> > >> > >> On Fri, Jan 23, 2015, at 12:49 PM, Mike Bayer wrote: > >>> Mike Bayer <mba...@redhat.com> wrote: > >>> > >>>> Ihar Hrachyshka <ihrac...@redhat.com> wrote: > >>>> > >>>>> On 01/23/2015 05:38 PM, Mike Bayer wrote: > >>>>>> Doug Hellmann <d...@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:
OK. I'll have to think about that. We've been trying to move away from import-time side-effects elsewhere (especially with configuration options) so we may want to think about doing the decoration at runtime, either through a hook discovered by oslo.context or by placing the call right in oslo.context. Let's talk about options this week. > > > > 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. We can leave the function in the public API, but oslo.log assumes the application is using a context class subclassed from the base class provided in oslo.context. As we evolve that integration, we'll make appropriate changes to the base class so they will usually be transparent to the application code, so it's going to be safer to just use the base class we provide. Doug > > 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 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
