Open Stack

On 03/03/14 at 06:17pm, Jay Pipes wrote:
>On Mon, 2014-03-03 at 17:56 -0500, Andrew Laski wrote:
>> 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?
>
>Any changes that we make to V2 will prolong its life. I think you will
>agree with this, yes?
>
>My main point is a philosophical one: if we scrap the V3 effort and
>decide to instead make changes to V2, then by nature, I think we will
>delay the ability to make more significant changes to the API.
>
>I'd like to work on a brand new (v4?) Compute API that dramatically
>changes the way that compute operations are made. If we make changes to
>the V2 API and extend its life, I don't have as much incentive to work
>on a brand new API version, since I've already seen that even minor
>changes like those in the V3 API can't make it into mainline in 3
>release cycles. Like I said, it's philosophical.
>

Totally understand.  But I would contend that it's because v3 is mostly 
minor changes that we're even having this conversation.

>> 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?
>
>See above. It's about the statement that this proposal makes to those
>developers who might have been considering contributing improvements to
>the Compute API.
>
>Best,
>-jay
>
>> >> > 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
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev