Re: [openstack-dev] [nova] Future of the Nova API

2014-03-03 Thread Steve Gordon
- Original Message - Hi Steve, On Sat, 1 Mar 2014 16:14:19 -0500 (EST) Steve Gordon sgor...@redhat.com wrote: [SNIP] My feeling both with my product hat and my upstream documentation contributor hat on knowing some of the issues we've had there in the past is that one release

Re: [openstack-dev] [nova] Future of the Nova API

2014-03-03 Thread Chris Friesen
On 03/03/2014 08:14 AM, Steve Gordon wrote: I would be interested in your opinion on the impact of a V2 version release which had backwards incompatibility in only one area - and that is input validation. So only apps/SDKs which are currently misusing the API (I think the most common problem

Re: [openstack-dev] [nova] Future of the Nova API

2014-03-01 Thread Steve Gordon
- Original Message - Howdy! I’m a Product Manager for Cloud Servers at Rackspace, and wanted to add a bit to what Behrens is saying. I'm a Product Manager covering OpenStack over at Red Hat - and largely concentrating on Nova no less, so I'll jump in and provide the view from my side

Re: [openstack-dev] [nova] Future of the Nova API

2014-03-01 Thread Christopher Yeoh
Hi Steve, On Sat, 1 Mar 2014 16:14:19 -0500 (EST) Steve Gordon sgor...@redhat.com wrote: That said I am still under the perhaps misguided impression that implementing tasks on v2 would not be *completely* impossible - smarter people than me have debated and will no doubt continue to debate

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-28 Thread Alex Xu
On 2014?02?28? 13:40, Chris Friesen wrote: On 02/27/2014 06:00 PM, Alex Xu wrote: Does mean our code looks like as below? if client_version 2: elif client_version 3 ... elif client_version 4: ... elif client_version 5: ... elif client_version 6: .. And we need test

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-28 Thread Day, Phil
-Original Message- From: Chris Behrens [mailto:cbehr...@codestud.com] Sent: 26 February 2014 22:05 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Future of the Nova API This thread is many messages deep now and I'm busy

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-28 Thread Day, Phil
-Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 24 February 2014 23:49 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Future of the Nova API Similarly with a Xen vs KVM situation I don't think its an extension related issue

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-28 Thread Day, Phil
To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Future of the Nova API -Original Message- From: Chris Behrens [mailto:cbehr...@codestud.com] Sent: 26 February 2014 22:05 To: OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-28 Thread Jay Pipes
On Fri, 2014-02-28 at 11:35 +, Day, Phil wrote: -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 24 February 2014 23:49 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Future of the Nova API Similarly with a Xen vs KVM

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-28 Thread Christopher Lefelhocz
: [openstack-dev] [nova] Future of the Nova API -Original Message- From: Chris Behrens [mailto:cbehr...@codestud.com] Sent: 26 February 2014 22:05 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Future of the Nova API This thread

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Dan Smith
So I think once we start returning different response codes, or completely different structures (such as the tasks change will be), it doesn't matter if we make the change in effect by invoking /v2 prefix or /v3 prefix or we look for a header. Its a major api revision. I don't think we should

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Chris Friesen
On 02/27/2014 08:43 AM, Dan Smith wrote: So I think once we start returning different response codes, or completely different structures (such as the tasks change will be), it doesn't matter if we make the change in effect by invoking /v2 prefix or /v3 prefix or we look for a header. Its a major

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Dan Smith
Sure, but that's still functionally equivalent to using the /v2 prefix. So we could chuck the current /v3 code and do: /v2: Current thing /v3: invalid, not supported /v4: added simple task return for server create /v5: added the event extension /v6: added a new event for cinder to the

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Sean Dague
On 02/27/2014 11:05 AM, Dan Smith wrote: Sure, but that's still functionally equivalent to using the /v2 prefix. So we could chuck the current /v3 code and do: /v2: Current thing /v3: invalid, not supported /v4: added simple task return for server create /v5: added the event extension

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Dan Smith
I do think client headers instead of urls have some pragmatic approach here that is very attractive. Will definitely need a good chunk of plumbing to support that in a sane way in the tree that keeps the overhead from a review perspective low. Aside from some helper functions to make this

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Christopher Yeoh
On Thu, 27 Feb 2014 09:41:45 -0800 Dan Smith d...@danplanet.com wrote: Aside from some helper functions to make this consistent, and some things to say here's the code I want to return, but compat clients need /this/ code, I think this actually gets us most of the way there:

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Christopher Yeoh
On Thu, 27 Feb 2014 12:02:45 -0500 Sean Dague s...@dague.net wrote: I do think client headers instead of urls have some pragmatic approach here that is very attractive. Will definitely need a good chunk of plumbing to support that in a sane way in the tree that keeps the overhead from a

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Dan Smith
So whilst we still have extensions (and that's a separate debate) we need versioning on a per extension basis. Otherwise people are forced to upgrade their extensions in lockstep with each other. I think that some people would argue that requiring the extensions to go together linearly is a

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Monty Taylor
Sorry for the top post. I was asked to look at this thread and toss in my €0.02 but I do not believe I could possibly read this whole thread - I'm too jet lagged. So... As a current large-scale production consumer of the API, I don't care at all as long as python-novaclient keeps working at

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Alex Xu
On 2014?02?28? 00:05, Dan Smith wrote: Sure, but that's still functionally equivalent to using the /v2 prefix. So we could chuck the current /v3 code and do: /v2: Current thing /v3: invalid, not supported /v4: added simple task return for server create /v5: added the event extension /v6:

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Joshua Harlow
, February 27, 2014 at 3:30 PM To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Future of the Nova API Sorry for the top post. I was asked to look at this thread and toss in my €0.02 but I do not believe I could possibly read this whole thread

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Jay Pipes
On Fri, 2014-02-28 at 00:30 +0100, Monty Taylor wrote: Sorry for the top post. I was asked to look at this thread and toss in my €0.02 but I do not believe I could possibly read this whole thread - I'm too jet lagged. So... As a current large-scale production consumer of the API, I don't

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-27 Thread Chris Friesen
On 02/27/2014 06:00 PM, Alex Xu wrote: Does mean our code looks like as below? if client_version 2: elif client_version 3 ... elif client_version 4: ... elif client_version 5: ... elif client_version 6: .. And we need test each version... That looks bad... I don't

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Thierry Carrez
Kenichi Oomichi wrote: From: Christopher Yeoh [mailto:cbky...@gmail.com] So the problem here is what we consider a bug becomes a feature from a user of the API point of view. Eg they really shouldn't be passing some data in a request, but its ignored and doesn't cause any issues and the

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Russell Bryant
On 02/25/2014 05:47 PM, Dan Smith wrote: Yeah, so objects is the big one here. Objects, and everything else. With no-db-compute we did it for a couple cycles, then objects, next it will be retooling flows to conductor, then dealing with tasks, talking to gantt, etc. It's not going to end any

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Dan Smith
So I was thinking about this and Ken'ichi has basically said pretty much the same thing in his reply to this thread. I don't think it makes client moves any easier though - this is all about lowering our maintenance costs. So, in the other fork of this thread, I think you said we can't

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Dan Smith
We may need to differentiate between breaking the API and breaking corner-case behavior. Totally agreed. In one case you force everyone in the ecosystem to adapt (the libraries, the end user code). In the other you only (potentially) affect those that were not following the API correctly.

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Joe Gordon
On Wed, Feb 26, 2014 at 6:38 AM, Dan Smith d...@danplanet.com wrote: We may need to differentiate between breaking the API and breaking corner-case behavior. Totally agreed. In one case you force everyone in the ecosystem to adapt (the libraries, the end user code). In the other you only

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Dan Smith
Users actually care about the latter. If the API accepts 'red' as a valid UUID then that is part of the implicit contract. Yeah, but right now, many of those things are would fail on postgres and succeed on mysql (not uuids necessarily, but others). Since we can't honor them in all cases, I

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Chris Behrens
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

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Christopher Yeoh
On Wed, 26 Feb 2014 09:28:20 -0800 Dan Smith d...@danplanet.com wrote: If we do go down this route of changing the v2 API like this, it would be nice to bump the minor version as well, so when a user has to distinguish between the two versions they don't have to say Havana V2 vs Icehouse

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Christopher Yeoh
On Wed, 26 Feb 2014 11:40:25 +0100 Thierry Carrez thie...@openstack.org wrote: We may need to differentiate between breaking the API and breaking corner-case behavior. In one case you force everyone in the ecosystem to adapt (the libraries, the end user code). In the other you only

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Dan Smith
So if we make backwards incompatible changes we really need a major version bump. Minor versions don't cut it, because the expectation is you have API stability within a major version. I disagree. If the client declares support for it, I think we can very reasonably return new stuff. If we

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Christopher Yeoh
On Wed, 26 Feb 2014 06:29:02 -0800 Dan Smith d...@danplanet.com wrote: So I was thinking about this and Ken'ichi has basically said pretty much the same thing in his reply to this thread. I don't think it makes client moves any easier though - this is all about lowering our maintenance

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Christopher Yeoh
On Wed, 26 Feb 2014 16:04:38 -0600 Chris Behrens cbehr...@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

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Chris Behrens
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 cbky...@gmail.com wrote: On Wed, 26 Feb 2014 16:04:38 -0600 Chris Behrens

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Alex Xu
On 2014年02月26日 18:40, Thierry Carrez wrote: Kenichi Oomichi wrote: From: Christopher Yeoh [mailto:cbky...@gmail.com] So the problem here is what we consider a bug becomes a feature from a user of the API point of view. Eg they really shouldn't be passing some data in a request, but its ignored

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Kenichi Oomichi
-Original Message- From: Alex Xu [mailto:x...@linux.vnet.ibm.com] Sent: Thursday, February 27, 2014 11:44 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Future of the Nova API On 2014年02月26日 18:40, Thierry Carrez wrote: Kenichi Oomichi wrote

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Chris Friesen
On 02/26/2014 04:50 PM, Dan Smith wrote: So if we make backwards incompatible changes we really need a major version bump. Minor versions don't cut it, because the expectation is you have API stability within a major version. I disagree. If the client declares support for it, I think we can

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Christopher Yeoh
On Thu, 27 Feb 2014 03:38:25 + Kenichi Oomichi oomi...@mxs.nes.nec.co.jp wrote: v3: This is the total new api. it's with CamelCase fixing, stronger input vaildation, api policy checks, and task api. v2.1: This is based on v3, we transform the v2 request into v3 request(then they

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Thomas Duesing
Howdy! I’m a Product Manager for Cloud Servers at Rackspace, and wanted to add a bit to what Behrens is saying. At Rackspace, we’ve experienced something like this (if you squint and look at it sideways) in the operation of our non-OpenStack cloud (“first gen Cloud Servers”) alongside our

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-26 Thread Christopher Yeoh
On Wed, 26 Feb 2014 14:50:46 -0800 Dan Smith d...@danplanet.com wrote: I disagree. If the client declares support for it, I think we can very reasonably return new stuff. If we take what we have today in v2 and call that 2, then we could make novaclient send this header: Accept:

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Christopher Yeoh
On Mon, 24 Feb 2014 21:15:30 -0500 Russell Bryant rbry...@redhat.com wrote: CC'ing the openstack-operators mailing list to get a wider set of feedback on this question. On 02/24/2014 05:26 PM, Christopher Yeoh wrote: 1) Continue as we have been, and plan to release v3 once we have a

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread John Garbutt
On 24 February 2014 18:11, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 2/24/2014 10:13 AM, Russell Bryant wrote: On 02/24/2014 01:50 AM, Christopher Yeoh wrote: Hi, There has recently been some speculation around the V3 API and whether we should go forward with it or instead

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread John Garbutt
On 25 February 2014 06:11, Christopher Yeoh cbky...@gmail.com wrote: On Mon, 24 Feb 2014 17:37:04 -0800 Dan Smith d...@danplanet.com wrote: onSharedStorage = True on_shared_storage = False This is a good example. I'm not sure it's worth breaking users _or_ introducing a new microversion

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread John Garbutt
On 25 February 2014 09:44, Christopher Yeoh cbky...@gmail.com wrote: On Mon, 24 Feb 2014 21:15:30 -0500 Russell Bryant rbry...@redhat.com wrote: CC'ing the openstack-operators mailing list to get a wider set of feedback on this question. On 02/24/2014 05:26 PM, Christopher Yeoh wrote: 1)

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Thierry Carrez
Sean Dague wrote: So, that begs a new approach. Because I think at this point even if we did put out Nova v3, there can never be a v4. It's too much, too big, and doesn't fit in the incremental nature of the project. So whatever gets decided about v3, the thing that's important to me is a sane

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Christopher Yeoh
On Tue, 25 Feb 2014 10:31:42 + John Garbutt j...@johngarbutt.com wrote: On 25 February 2014 06:11, Christopher Yeoh cbky...@gmail.com wrote: On Mon, 24 Feb 2014 17:37:04 -0800 Dan Smith d...@danplanet.com wrote: onSharedStorage = True on_shared_storage = False This is a good

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Ken'ichi Ohmichi
2014-02-25 19:48 GMT+09:00 Thierry Carrez thie...@openstack.org: Sean Dague wrote: So, that begs a new approach. Because I think at this point even if we did put out Nova v3, there can never be a v4. It's too much, too big, and doesn't fit in the incremental nature of the project. So whatever

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Alex Xu
On 2014年02月25日 21:17, Ken'ichi Ohmichi wrote: 2014-02-25 19:48 GMT+09:00 Thierry Carrez thie...@openstack.org: Sean Dague wrote: So, that begs a new approach. Because I think at this point even if we did put out Nova v3, there can never be a v4. It's too much, too big, and doesn't fit in the

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Sean Dague
On 02/25/2014 08:17 AM, Ken'ichi Ohmichi wrote: 2014-02-25 19:48 GMT+09:00 Thierry Carrez thie...@openstack.org: Sean Dague wrote: So, that begs a new approach. Because I think at this point even if we did put out Nova v3, there can never be a v4. It's too much, too big, and doesn't fit in

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Dan Smith
I thought micro versioning was so we could make backwards compatible changes. If we make breaking changes we need to support the old and the new for a little while. Adding a new field alongside an old one in a structure that we return is not a breaking change to me, IMHO. We can clean up the

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Dan Smith
I think we need to find an alternative way to support the new and old formats, like Accepts Headers, and retro-fitting a version to extensions so we can easily advertise new attributes, to those parsers that will break when they encounter those kinds of things. Agreed. Now I am tempted to

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Matt Riedemann
On 2/25/2014 6:00 AM, Christopher Yeoh wrote: On Tue, 25 Feb 2014 10:31:42 + John Garbutt j...@johngarbutt.com wrote: On 25 February 2014 06:11, Christopher Yeoh cbky...@gmail.com wrote: On Mon, 24 Feb 2014 17:37:04 -0800 Dan Smith d...@danplanet.com wrote: onSharedStorage = True

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Dan Smith
+1, seems would could explore for another cycle just to find out that backporting everything to V2 isn't going to be what we want, and now we've just wasted more time. If we say it's just deprecated and frozen against new features, then it's maintenance is just limited to bug fixes right?

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Matt Riedemann
On Tuesday, February 25, 2014 4:02:13 PM, Dan Smith wrote: +1, seems would could explore for another cycle just to find out that backporting everything to V2 isn't going to be what we want, and now we've just wasted more time. If we say it's just deprecated and frozen against new features,

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Dan Smith
Yeah, so objects is the big one here. Objects, and everything else. With no-db-compute we did it for a couple cycles, then objects, next it will be retooling flows to conductor, then dealing with tasks, talking to gantt, etc. It's not going to end any time soon. So what kind of reaction are

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Jay Pipes
On Tue, 2014-02-25 at 09:26 -0500, Sean Dague wrote: What I want out of Nova API at the end of the day: 1. a way to discover what the API is because this massively simplifies writing clients, SDKs, tests, and documentation. All those pipelines are terribly manual, and have errors in them

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Christopher Yeoh
On Tue, 25 Feb 2014 09:26:09 -0500 Sean Dague s...@dague.net wrote: On 02/25/2014 08:17 AM, Ken'ichi Ohmichi wrote: 2014-02-25 19:48 GMT+09:00 Thierry Carrez thie...@openstack.org: Sean Dague wrote: So, that begs a new approach. Because I think at this point even if we did put out Nova

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Christopher Yeoh
On Tue, 25 Feb 2014 14:47:16 -0800 Dan Smith d...@danplanet.com wrote: Yeah, so objects is the big one here. Objects, and everything else. With no-db-compute we did it for a couple cycles, then objects, next it will be retooling flows to conductor, then dealing with tasks, talking to gantt,

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Christopher Yeoh
On Tue, 25 Feb 2014 10:37:14 + John Garbutt j...@johngarbutt.com wrote: Now I am tempted to say we morph the V3 code to also produce the V2 responses. And change the v3 API, so thats easier to do, and easier for clients to move (like don't change URLs unless we really have to). I know

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Dan Smith
This would reduce the amount of duplication which is required (I doubt we could remove all duplication though) and whether its worth it for say the rescue example is debatable. But for those cases you'd only need to make the modification in one file. Don't forget the cases where the call

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Kenichi Oomichi
-Original Message- From: Christopher Yeoh [mailto:cbky...@gmail.com] Sent: Wednesday, February 26, 2014 11:33 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Future of the Nova API On Tue, 25 Feb 2014 09:26:09 -0500 Sean Dague s...@dague.net wrote

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-25 Thread Christopher Yeoh
On Tue, 25 Feb 2014 20:52:14 -0800 Dan Smith d...@danplanet.com wrote: This would reduce the amount of duplication which is required (I doubt we could remove all duplication though) and whether its worth it for say the rescue example is debatable. But for those cases you'd only need to

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Christopher Yeoh
On Mon, 24 Feb 2014 02:06:50 -0500 Jay Pipes jaypi...@gmail.com wrote: On Mon, 2014-02-24 at 17:20 +1030, Christopher Yeoh wrote: - Proposed way forward: - Release the V3 API in Juno with nova-network and tasks support - Feature freeze the V2 API when the V3 API is released - Set

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Dan Smith
- We want to make backwards incompatible changes to the API and whether we do it in-place with V2 or by releasing V3 we'll have some form of dual API support burden. IMHO, the cost of maintaining both APIs (which are largely duplicated) for almost any amount of time outweighs the cost of

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Jay Pipes
On Mon, 2014-02-24 at 20:22 +1030, Christopher Yeoh wrote: On Mon, 24 Feb 2014 02:06:50 -0500 Jay Pipes jaypi...@gmail.com wrote: On Mon, 2014-02-24 at 17:20 +1030, Christopher Yeoh wrote: - Proposed way forward: - Release the V3 API in Juno with nova-network and tasks support -

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Russell Bryant
On 02/24/2014 01:50 AM, Christopher Yeoh wrote: Hi, There has recently been some speculation around the V3 API and whether we should go forward with it or instead backport many of the changes to the V2 API. I believe that the core of the concern is the extra maintenance and test burden that

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Matt Riedemann
On 2/24/2014 10:13 AM, Russell Bryant wrote: On 02/24/2014 01:50 AM, Christopher Yeoh wrote: Hi, There has recently been some speculation around the V3 API and whether we should go forward with it or instead backport many of the changes to the V2 API. I believe that the core of the concern

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Christopher Yeoh
On Mon, 24 Feb 2014 07:56:19 -0800 Dan Smith d...@danplanet.com wrote: - We want to make backwards incompatible changes to the API and whether we do it in-place with V2 or by releasing V3 we'll have some form of dual API support burden. IMHO, the cost of maintaining both APIs (which

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Morgan Fainberg
On the topic of backwards incompatible changes: I strongly believe that breaking current clients that use the APIs directly is the worst option possible. All the arguments about needing to know which APIs work based upon which backend drivers are used are all valid, but making an API

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Christopher Yeoh
On Mon, 24 Feb 2014 11:13:11 -0500 Russell Bryant rbry...@redhat.com wrote: Yes, this is a major concern. It has taken an enormous amount of work to get to where we are, and v3 isn't done. It's a good time to re-evaluate whether we are on the right path. So I think its important to point

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Russell Bryant
On 02/24/2014 05:01 PM, Morgan Fainberg wrote: On the topic of backwards incompatible changes: I strongly believe that breaking current clients that use the APIs directly is the worst option possible. All the arguments about needing to know which APIs work based upon which backend drivers

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Dan Smith
The API layer is a actually quite a very thin layer on top of the rest of Nova. Most of the logic in the API code is really just checking incoming data, calling the underlying nova logic and then massaging what is returned in the correct format. So as soon as you change the format the cost of

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Chris Friesen
On 02/24/2014 04:01 PM, Morgan Fainberg wrote: TL;DR, “don’t break the contract”. If we are seriously making incompatible changes (and we will be regardless of the direction) the only reasonable option is a new major version. Agreed. I don't think we can possibly consider making

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Christopher Yeoh
On Mon, 24 Feb 2014 11:48:41 -0500 Jay Pipes jaypi...@gmail.com wrote: It's not about forcing providers to support all of the public API. It's about providing a single, well-documented, consistent HTTP REST API for *consumers* of that API. Whether a provider chooses to, for example, deploy

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Russell Bryant
On 02/24/2014 05:26 PM, Christopher Yeoh wrote: - Whilst we have existing users of the API we also have a lot more users in the future. It would be much better to allow them to use the API we want to get to as soon as possible, rather than trying to evolve the V2 API and forcing them

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Michael Davies
On Tue, Feb 25, 2014 at 8:31 AM, Morgan Fainberg m...@metacloud.com wrote: On the topic of backwards incompatible changes: I strongly believe that breaking current clients that use the APIs directly is the worst option possible. All the arguments about needing to know which APIs work based

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Sean Dague
It's really easy to just say don't break the contract. Until we got the level of testing that we currently have in Tempest, the contract was broken pretty regularly. I'm sure there are still breaks in it around the edges where we aren't clamping down on people today. So the history of v2 is far

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Russell Bryant
On 02/24/2014 05:49 PM, Michael Davies wrote: On Tue, Feb 25, 2014 at 8:31 AM, Morgan Fainberg m...@metacloud.com mailto:m...@metacloud.com wrote: On the topic of backwards incompatible changes: I strongly believe that breaking current clients that use the APIs directly is the

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Chris Friesen
On 02/24/2014 04:59 PM, Sean Dague wrote: So, that begs a new approach. Because I think at this point even if we did put out Nova v3, there can never be a v4. It's too much, too big, and doesn't fit in the incremental nature of the project. Does it necessarily need to be that way though?

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Sean Dague
On 02/24/2014 06:13 PM, Chris Friesen wrote: On 02/24/2014 04:59 PM, Sean Dague wrote: So, that begs a new approach. Because I think at this point even if we did put out Nova v3, there can never be a v4. It's too much, too big, and doesn't fit in the incremental nature of the project.

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Jay Pipes
On Mon, 2014-02-24 at 14:01 -0800, Morgan Fainberg wrote: TL;DR, “don’t break the contract”. If we are seriously making incompatible changes (and we will be regardless of the direction) the only reasonable option is a new major version. 100% agreement. Note that when I asked Chris when we

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Jay Pipes
On Mon, 2014-02-24 at 17:59 -0500, Sean Dague wrote: So we do really need to be pragmatic here as well. Because our experience with v3 so far has been doing a major version bump on Nova is a minimum of 2 years, and that doesn't reach a completion point that anyone's happy with to switch over.

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Jay Pipes
On Tue, 2014-02-25 at 09:11 +1030, Christopher Yeoh wrote: On Mon, 24 Feb 2014 11:48:41 -0500 Jay Pipes jaypi...@gmail.com wrote: It's not about forcing providers to support all of the public API. It's about providing a single, well-documented, consistent HTTP REST API for *consumers* of

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Sean Dague
On 02/24/2014 06:31 PM, Jay Pipes wrote: On Mon, 2014-02-24 at 17:59 -0500, Sean Dague wrote: So we do really need to be pragmatic here as well. Because our experience with v3 so far has been doing a major version bump on Nova is a minimum of 2 years, and that doesn't reach a completion point

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Chris Friesen
On 02/24/2014 05:17 PM, Sean Dague wrote: On 02/24/2014 06:13 PM, Chris Friesen wrote: On 02/24/2014 04:59 PM, Sean Dague wrote: So, that begs a new approach. Because I think at this point even if we did put out Nova v3, there can never be a v4. It's too much, too big, and doesn't fit in the

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Morgan Fainberg
Yes, micro-versioning is most likely a better approach, and I’m a fan of using that to gain the benefits of V3 without changing for the sake of change. Ideally in a versioned API we should be versioning a smaller surface area than “THE WHOLE API” if at all possible. If we kept the old “version”

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Christopher Yeoh
On Mon, 24 Feb 2014 17:47:51 -0500 Russell Bryant rbry...@redhat.com wrote: On 02/24/2014 05:26 PM, Christopher Yeoh wrote: - Whilst we have existing users of the API we also have a lot more users in the future. It would be much better to allow them to use the API we want to get to as

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Christopher Yeoh
On Mon, 24 Feb 2014 15:54:42 -0800 Morgan Fainberg m...@metacloud.com wrote: Yes, micro-versioning is most likely a better approach, and I’m a fan of using that to gain the benefits of V3 without changing for the sake of change. Ideally in a versioned API we should be versioning a smaller

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Dan Smith
So the deprecation message in the patch says: LOG.warning(_('XML support has been deprecated and will be removed in the Juno release.')) perhaps that should be changed :-) Maybe, but I think we can continue with the plan to rip it out in Juno. In the past when we've asked,

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Christopher Yeoh
On Mon, 24 Feb 2014 16:20:12 -0800 Dan Smith d...@danplanet.com wrote: So the deprecation message in the patch says: LOG.warning(_('XML support has been deprecated and will be removed in the Juno release.')) perhaps that should be changed :-) Maybe, but I think we

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Christopher Yeoh
On Mon, 24 Feb 2014 18:17:34 -0500 Sean Dague s...@dague.net wrote: On 02/24/2014 06:13 PM, Chris Friesen wrote: On 02/24/2014 04:59 PM, Sean Dague wrote: So, that begs a new approach. Because I think at this point even if we did put out Nova v3, there can never be a v4. It's too much,

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Dan Smith
onSharedStorage = True on_shared_storage = False This is a good example. I'm not sure it's worth breaking users _or_ introducing a new microversion for something like this. This is definitely what I would call a purity concern as opposed to usability. Things like the twenty different datetime

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Russell Bryant
On 02/24/2014 08:16 PM, Christopher Yeoh wrote: On Mon, 24 Feb 2014 16:20:12 -0800 Dan Smith d...@danplanet.com wrote: So the deprecation message in the patch says: LOG.warning(_('XML support has been deprecated and will be removed in the Juno release.')) perhaps that

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Russell Bryant
On 02/24/2014 08:31 PM, Christopher Yeoh wrote: On Mon, 24 Feb 2014 18:17:34 -0500 Sean Dague s...@dague.net wrote: On 02/24/2014 06:13 PM, Chris Friesen wrote: On 02/24/2014 04:59 PM, Sean Dague wrote: So, that begs a new approach. Because I think at this point even if we did put out

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Russell Bryant
CC'ing the openstack-operators mailing list to get a wider set of feedback on this question. On 02/24/2014 05:26 PM, Christopher Yeoh wrote: 1) Continue as we have been, and plan to release v3 once we have a compelling enough feature set. So I think we should release in Juno even if its only

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Kenichi Oomichi
-Original Message- From: Christopher Yeoh [mailto:cbky...@gmail.com] Sent: Tuesday, February 25, 2014 6:35 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Future of the Nova API - twice the code - different enough

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-24 Thread Christopher Yeoh
On Mon, 24 Feb 2014 17:37:04 -0800 Dan Smith d...@danplanet.com wrote: onSharedStorage = True on_shared_storage = False This is a good example. I'm not sure it's worth breaking users _or_ introducing a new microversion for something like this. This is definitely what I would call a

Re: [openstack-dev] [nova] Future of the Nova API

2014-02-23 Thread Jay Pipes
On Mon, 2014-02-24 at 17:20 +1030, Christopher Yeoh wrote: - Proposed way forward: - Release the V3 API in Juno with nova-network and tasks support - Feature freeze the V2 API when the V3 API is released - Set the timeline for deprecation of V2 so users have a lot of warning

  1   2   >