Open Stack

Again, just another quick response, but if we can find a way to merge v2 into the current v3 code, so that we don't have dual maintenance, that would be really nice.

> On Feb 26, 2014, at 5:15 PM, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
> 
> On Wed, 26 Feb 2014 16:04:38 -0600
> Chris Behrens <cbehrens at codestud.com> wrote:
>> 
>> This thread is many messages deep now and I’m busy with a conference
>> this week, but I wanted to carry over my opinion from the other “v3
>> API in Icehouse” thread and add a little to it.
>> 
>> Bumping versions is painful. v2 is going to need to live for “a long
>> time” to create the least amount of pain. I would think that at least
>> anyone running a decent sized Public Cloud would agree, if not anyone
>> just running any sort of decent sized cloud. I don’t think there’s a
>> compelling enough reason to deprecate v2 and cause havoc with what we
>> currently have in v3. I’d like us to spend more time on the proposed
>> “tasks” changes. And I think we need more time to figure out if we’re
>> doing versioning in the correct way. If we’ve got it wrong, a v3
>> doesn’t fix the problem and we’ll just be causing more havoc with a
>> v4.
> 
> So I guess I agree tasks is something we should develop further and
> that makes significant non backwards compatible changes to the API -
> which is the major reason why we delayed V3. And its really important
> that we get those changes right so we don't need a v4.
> 
> However, keeping V3 experimental indefinitely doesn't actually remove
> the dual maintenance burden. The only way to do that is eventually
> remove either the V2 or V3 version or do the suggested backport. 
> 
> We've pretty well established that starting a fresh v3 API is a
> multi cycle effort. If we remove the V3 api code in Juno and then
> start working on a new major version bump at a later date at say L or
> M it'll be another multi cycle effort which I doubt would be
> feasible, especially with people knowing there is the real risk at the
> end that it'll just get thrown away. 
> 
> And the alternative of not removing V3 leaves the extra maintenance
> burden. So whilst I agree with making sure we get it right but I'm
> wondering exactly what you mean by taking more time to figure out
> what we're doing - is it removing the V3 API code and just coping
> with extra maintenance burden? Or removing it and then trying to do
> a big multi cycle effort again a few cycles down the track?
> 
> Chris
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev