You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Andrew Bayer <an...@gmail.com> on 2013/08/22 03:40:06 UTC
Getting rid of async, blobstore, and 1.7.0
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?
A.
Re: Getting rid of async, blobstore, and 1.7.0
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Aug 22, 2013, at 8:12 AM, Andrew Phillips wrote:
>> 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?
>
> To me, this has high priority because it's about getting the "new" provider programming model in place, and with the new potential development community at Apache I'd like to get this done as soon as possible, ideally in the first major Apache release.
>
> If not all of the providers make it, that would be OK, I guess, as long as we have sufficient "good" examples to point people towards.
>
> In order to help balance this out: what do we feel are the other Really Important changes/features we're pushing out with 1.7.0, which we would rather not delay?
I'm going to have a look at this this afternoon and try to figure out the scope of the work to de-async all of the OpenStack/Rackspace stuff. My initial suspicion is that it's going to be pretty thorny due to async stuff being used in BlobStore. We'll see.
Everett
Re: Getting rid of async, blobstore, and 1.7.0
Posted by Andrew Phillips <ap...@qrmedia.com>.
> 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?
To me, this has high priority because it's about getting the "new"
provider programming model in place, and with the new potential
development community at Apache I'd like to get this done as soon as
possible, ideally in the first major Apache release.
If not all of the providers make it, that would be OK, I guess, as
long as we have sufficient "good" examples to point people towards.
In order to help balance this out: what do we feel are the other
Really Important changes/features we're pushing out with 1.7.0, which
we would rather not delay?
ap
Re: Getting rid of async, blobstore, and 1.7.0
Posted by Andrew Gaul <ga...@apache.org>.
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 <an...@gmail.com>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 <
> > everett.toews@rackspace.com> 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 <ga...@apache.org> 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/
Re: Getting rid of async, blobstore, and 1.7.0
Posted by Andrew Gaul <ga...@apache.org>.
On Tue, Aug 27, 2013 at 02:13:10AM +0200, Andrew Phillips 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.
>
> I wouldn't like to push it out to "not ever", but I'd be OK with postponing
> it for 1.7.x if we think it would risk delaying 1.7.0.
>
> I'd also like to see whether getting rid of async has some of the hoped-for
> effects, e.g. that new committers find the core less forbidding...
Not just new committers. ;-)
--
Andrew Gaul
http://gaul.org/
Re: Getting rid of async, blobstore, and 1.7.0
Posted by Andrew Phillips <ap...@qrmedia.com>.
> 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.
I wouldn't like to push it out to "not ever", but I'd be OK with
postponing it for 1.7.x if we think it would risk delaying 1.7.0.
I'd also like to see whether getting rid of async has some of the
hoped-for effects, e.g. that new committers find the core less
forbidding...
ap
Re: Getting rid of async, blobstore, and 1.7.0
Posted by Andrew Bayer <an...@gmail.com>.
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 <an...@gmail.com>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 <
> everett.toews@rackspace.com> 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 <ga...@apache.org> 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/
>>
>>
>
Re: Getting rid of async, blobstore, and 1.7.0
Posted by Andrew Bayer <an...@gmail.com>.
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
<ev...@rackspace.com>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 <ga...@apache.org> 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/
>
>
Re: Getting rid of async, blobstore, and 1.7.0
Posted by Everett Toews <ev...@RACKSPACE.COM>.
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 <ga...@apache.org> 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/
Re: Getting rid of async, blobstore, and 1.7.0
Posted by Andrew Gaul <ga...@apache.org>.
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 <ga...@apache.org> 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/
Re: Getting rid of async, blobstore, and 1.7.0
Posted by Andrew Bayer <an...@gmail.com>.
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 <ga...@apache.org> 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/
>
Re: Getting rid of async, blobstore, and 1.7.0
Posted by Andrew Gaul <ga...@apache.org>.
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/