I will look at this over the weekend. Note that Blobstore has more interesting uses of async due to clear container, multi-part upload, and others. Can we use some fake sameThreadExecutor shims to work around keystone async in the short-term?
On Thu, Aug 22, 2013 at 01:43:05PM -0400, Andrew Bayer wrote: > I think all I need is someone who knows blobstore to get the blobstore > abstraction able to support not having async - I can probably go nuts for a > few days and get all the blobstore implementations de-asynced once the > abstraction is ready. > > A. > > > On Thu, Aug 22, 2013 at 1:17 PM, Andrew Gaul <[email protected]> wrote: > > > On Wed, Aug 21, 2013 at 09:40:06PM -0400, Andrew Bayer wrote: > > > So most of the compute providers/APIs in core are now async-free on > > master > > > - the only exceptions I can think of off the top of my head are the > > vcloud > > > ones, the old rackspace ones, and the nova ones. The vcloud ones I'll get > > > around to sometime in the next couple weeks - that's just a matter of > > > gutting them out. But the rackspace/nova ones are a lot hairier. > > > > > > When I tried de-asyncing the cloudservers API, I found I had to de-async > > > the keystone v1 API as well - and that can't actually go live until > > > cloudfiles is able to de-async too. I haven't verified, but I'm pretty > > sure > > > it's the same situation for nova/keystone/swift. And cloudfiles/swift > > can't > > > de-async until blobstore itself supports non-async. > > > > > > So this brings up an important question. We're about 6 weeks from the > > > target date for 1.7.0 - can we actually get the blobstore stuff > > de-asynced > > > by then? Or are we going to need to push the de-async completion back > > 'til > > > 1.7.1/2/3/whatever? How high a priority should this be? > > > > I prefer to keep the date for 1.7.0 above all; we have features waiting > > for this release and we should not delay it. Also, maintaining 1.6.x > > will become increasingly difficult as the two branches diverge. > > Blobstore can remain async in 1.7.0 and we can address this in 1.8.0 > > (1.7.x feels inappropriate). However, we have so much progress on > > de-async for compute, let's do the minimum work on cloudfiles/swift to > > complete compute. I will step up for some of this, however, I do not > > understand how this interacts with some of the Swift rewrite work and > > perhaps someone at Rackspace can explain this and help me out as well? > > > > -- > > Andrew Gaul > > http://gaul.org/ > > -- Andrew Gaul http://gaul.org/
