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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
