I looked at de-async BlobStore over the weekend and am not clear on the parts blocking compute. I have a small commit to remove BlobStoreContext.getAsyncBlobStore but I suspect we need something more. Everett can you specify the minimum I need to do to unblock the compute effort? I will happily do this part, although I cannot commit to full blobstore de-async for 1.7. I have several other jclouds deliverables which I feel have higher priority than full de-async.
On Mon, Aug 26, 2013 at 04:46:16PM -0700, Andrew Bayer wrote: > 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/ > >> > >> > > -- Andrew Gaul http://gaul.org/
