I'd guess the same thing may be the case for Nova/Swift/Keystone, but don't quote me on that.
A. On Fri, Aug 23, 2013 at 3:55 PM, Everett Toews <[email protected]>wrote: > 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/ > >
