Open Stack

On 03/03/14 at 04:48pm, Jay Pipes wrote:
>On Mon, 2014-03-03 at 15:24 -0500, Russell Bryant wrote:
>> On 03/03/2014 02:59 PM, Jay Pipes wrote:
>> > -1 from me. Sounds like a way to avoid badly needed change and
>> > innovation in the API. When, for example, would we be able to propose a
>> > patch that removed API extensions entirely?
>>
>> v3 didn't address this at all, anyway.  I'm not even sure there's
>> consensus on it.  In any case, I think it's tangential and only relevant
>> if we're starting with a new API.
>
>I guess I am saying that if the ostensibly "limited" changes and
>standardization of Chris and others' V3 API work has now been decided is
>too risky to use or of not enough value to users, then the chance that a
>brand new API version seeing the light of day is pretty low. And that is
>disappointing to me. Feel free to tell me I'm nuts, though. I'd happily
>exchange my skepticism for some healthy optimism.

This isn't about the v3 API changes being too risky or not of value to
users.  What has been most concerning about the v3 API is the amount of
code it has introduced into the Nova tree and the amount of testing work
that has been required.  Doing this split once has been a pain but 
overall has been manageable up to this point, IMO.  But at this point we 
don't have any reasonable idea on when v2 can be removed, so it's 
potentially with us for good.  And while v3 improves the story around 
making API changes it doesn't address some of the things that caused us 
to look at v3 in the first place.  So we're potentially setting 
ourselves up to eventually hold three or more API versions in tree.  
Before going down that road we came up with a proposal that allows us to 
move forward in much the same way as v3 but with a lower maintenance 
burden.

What I would like to see is answers for how v3 can address some of the 
questions that are being asked of this proposal, such as removing API 
extensions entirely.  Or how would we add entirely new concepts like 
tasks?

Personally I love the changes that v3 provides, and want to see our API 
evolve and mature in the direction it's heading.  But I also want it to 
have real value.  Beyond a few renames and return code fixes what does 
it do that we can't do with v2?  That's the question I'm still asking 
myself.


>
>> > The inconsistent naming, capitalization, numerous worthless or pointless
>> > API extensions, ability to do similar or identical things in different
>> > ways, and the incorrect result/response codes makes the Nova API look
>> > immature and clownish. I'd love to see a competing proposal to this that
>> > looks towards the future and a day when we can be proud of the Compute
>> > API as a real differentiator vs. the EC2 API. As it stands, the v2 REST
>> > API just makes OpenStack Compute look subpar at best, IMO.
>>
>> Much of what you discuss is addressed in the document.
>
>Well, it's discussed in the document... in as much to say "we won't
>really change any of these things..."
>
>> I think the differentiation that you want comes from a new ground-up
>> API, and not what's being discussed here (v3, or further evolution of v2).
>
>Yes, but my concern about this proposal is that it reinforces the status
>quo and in so doing, slows down the pace of innovation at the API level.
>And, a slow pace of API innovation in turn inhibits innovation at layers
>of the code beneath the API.

What innovation is being slowed down?  This proposal was put together to 
compare against the current v3 effort and see if we can tease out these 
things.  What can we do in v3 that we can't do in v2?


>
>> > Feel free to accuse me of wanting my cake and eating it, too. I guess
>> > I'm just both hungry and impatient.
>>
>> Not that, exactly ... just ignoring some of the practicalities at hand,
>> I think.
>
>Fair enough. :)
>
>Best,
>-jay
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev