TL;DR I've come to the same conclusion. BlobStore is the lynch pin right now.
Here's what I've found. Improvements to the logic below is welcome. To unasync cloudservers we need to unasync openstack-common. If we unasync openstack-common, we need to unasync cloudfiles. If we unasync cloudfiles, we need to unasync BlobStore. If we can unasync cloudfiles, we can unasync openstack-keystone. (cloudfiles depends on both openstack-common and openstack-keystone) If we can unasync openstack-keystone, we can unasync the rest of the rackspace apis. If that's correct, unasyncing the BlobStore should unblock us for the rest of the unasync. Everett On Aug 22, 2013, at 1:19 PM, Andrew Gaul wrote: > 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/
