Open Stack

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. 

> 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