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/
