So the consensus seems to be to defer (or not ever) getting rid of async for blobstore, except what's needed to be able to support de-asynced Rackspace etc compute stuff.
Any counteropinions? (Oh, also, again barring any arguments against this, I'm gonna skip de-asyncing anything in labs - the AWS/Google stuff is de-asynced already, the OpenStack stuff I leave to the Rackers, Abiquo and a couple others are already de-asynced, and I couldn't give a crap about the rest!) A. On Fri, Aug 23, 2013 at 4:22 PM, Andrew Bayer <[email protected]>wrote: > 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/ >> >> >
