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

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 wou

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

- Original Message - > Hi Steve, > > On Sat, 1 Mar 2014 16:14:19 -0500 (EST) > Steve Gordon 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 cycle of

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

Hi Steve, On Sat, 1 Mar 2014 16:14:19 -0500 (EST) Steve Gordon 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 how practical/re

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

- 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 sid

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

al Message- >> From: Day, Phil >> Sent: 28 February 2014 11:07 >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [nova] Future of the Nova API >> >> > -Original Message- >> > From: Chris B

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

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

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

t; From: Day, Phil > Sent: 28 February 2014 11:07 > 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] > >

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

> -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 th

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 questions) > Subject: Re: [openstack-dev] [nova] Future of the Nova API > > > This thread is many m

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

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 t

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

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 d

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

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

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

:30 PM To: "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 - >I'm too jet lagged. So... &

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

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: added

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 - 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 th

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

> 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

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

On Thu, 27 Feb 2014 12:02:45 -0500 Sean Dague 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 review perspec

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

On Thu, 27 Feb 2014 09:41:45 -0800 Dan Smith 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: > > http://paste.openstack.

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

> 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

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 e

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

> 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

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

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

> 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 sh

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

On Wed, 26 Feb 2014 14:50:46 -0800 Dan Smith 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: application/json

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

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 Open

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

On Thu, 27 Feb 2014 03:38:25 + Kenichi Oomichi 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 are share same

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

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 ver

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

> -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

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

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

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 wrote: > > On Wed, 26 Feb 2014 16:04:38 -0600 > Chris Behrens wrote: >> >> Thi

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

On Wed, 26 Feb 2014 16:04:38 -0600 Chris Behrens 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 painful. v2 is going to

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

On Wed, 26 Feb 2014 06:29:02 -0800 Dan Smith 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 costs. > > S

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

> 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

On Wed, 26 Feb 2014 11:40:25 +0100 Thierry Carrez 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 > (potentially) affect those

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

On Wed, 26 Feb 2014 09:28:20 -0800 Dan Smith 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 V2, they

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

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 pain

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

> 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

On Wed, Feb 26, 2014 at 6:38 AM, Dan Smith 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 >> (potent

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

> 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 correctl

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

> 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 im

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

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 en

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

On Tue, 25 Feb 2014 22:15:42 -0800 Joe Gordon wrote: > So it turns out nova isn't the only OpenStack project to attempt a > full API revision. > > Keystone v3 - Grizzly > Glancev2 - Folsom > Cinder v2 - Grizzly > > Out of those 3, nova doesn't use any of them! (Although there are > blue

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

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 >> an

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

So it turns out nova isn't the only OpenStack project to attempt a full API revision. Keystone v3 - Grizzly Glancev2 - Folsom Cinder v2 - Grizzly Out of those 3, nova doesn't use any of them! (Although there are blueprints and patches up for cinder and glance v2, but they are still in rev

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

On Tue, 25 Feb 2014 20:52:14 -0800 Dan Smith 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 make the modi

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

> -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 -050

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

On Wed, 26 Feb 2014 15:14:55 +1030 Christopher Yeoh wrote: > On Tue, 25 Feb 2014 10:37:14 + > John Garbutt wrote: > > > > So I was pondering if its possible to write a decorator for v3 (not > json schema because we have to do some crazy stuff) that does the > equivalent of V2 input validat

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

> 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 c

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

On Tue, 25 Feb 2014 10:37:14 + John Garbutt 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 the risk for screw

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

On Tue, 25 Feb 2014 14:47:16 -0800 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 no

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

On Tue, 25 Feb 2014 09:26:09 -0500 Sean Dague wrote: > On 02/25/2014 08:17 AM, Ken'ichi Ohmichi wrote: > > 2014-02-25 19:48 GMT+09:00 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

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

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

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

> 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 t

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

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, t

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

> +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

On 2/25/2014 6:00 AM, Christopher Yeoh wrote: On Tue, 25 Feb 2014 10:31:42 + John Garbutt wrote: On 25 February 2014 06:11, Christopher Yeoh wrote: On Mon, 24 Feb 2014 17:37:04 -0800 Dan Smith wrote: onSharedStorage = True on_shared_storage = False This is a good example. I'm not

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

> 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

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

> 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

On 02/25/2014 08:17 AM, Ken'ichi Ohmichi wrote: > 2014-02-25 19:48 GMT+09:00 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 incremen

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

On 2014年02月25日 21:17, Ken'ichi Ohmichi wrote: 2014-02-25 19:48 GMT+09:00 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 t

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

2014-02-25 19:48 GMT+09:00 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

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

On Tue, 25 Feb 2014 10:31:42 + John Garbutt wrote: > On 25 February 2014 06:11, Christopher Yeoh wrote: > > On Mon, 24 Feb 2014 17:37:04 -0800 > > Dan Smith wrote: > > > >> > onSharedStorage = True > >> > on_shared_storage = False > >> > >> This is a good example. I'm not sure it's worth br

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

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 s

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

On 25 February 2014 09:44, Christopher Yeoh wrote: > On Mon, 24 Feb 2014 21:15:30 -0500 > Russell Bryant 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 b

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

On 25 February 2014 06:11, Christopher Yeoh wrote: > On Mon, 24 Feb 2014 17:37:04 -0800 > Dan Smith 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 th

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

On 24 February 2014 18:11, Matt Riedemann 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 backport

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

On Mon, 24 Feb 2014 21:15:30 -0500 Russell Bryant 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 > >> compelling en

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

On Mon, 24 Feb 2014 17:37:04 -0800 Dan Smith 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 "purity" concern

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

> -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

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

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

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

On 02/24/2014 08:31 PM, Christopher Yeoh wrote: > On Mon, 24 Feb 2014 18:17:34 -0500 > 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

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

On 02/24/2014 08:16 PM, Christopher Yeoh wrote: > On Mon, 24 Feb 2014 16:20:12 -0800 > Dan Smith 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 shou

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

> 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 date

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

On Mon, 24 Feb 2014 18:17:34 -0500 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, > >>

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

On Mon, 24 Feb 2014 16:20:12 -0800 Dan Smith 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 can c

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

> 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 a

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

On Mon, 24 Feb 2014 15:54:42 -0800 Morgan Fainberg 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 surface area than

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

On Mon, 24 Feb 2014 17:47:51 -0500 Russell Bryant 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 soon as p

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

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

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 i

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

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

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

On Tue, 2014-02-25 at 09:11 +1030, Christopher Yeoh wrote: > On Mon, 24 Feb 2014 11:48:41 -0500 > Jay Pipes 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.

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

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 ove

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

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 w

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

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

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? Mayb

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

On 02/24/2014 05:49 PM, Michael Davies wrote: > On Tue, Feb 25, 2014 at 8:31 AM, 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 opti

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

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

On Tue, Feb 25, 2014 at 8:31 AM, 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 back

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

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 forci

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

On Mon, 24 Feb 2014 11:48:41 -0500 Jay Pipes 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 with nova-networ

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

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 backwards-in

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

> 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 cos

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

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 driver

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

On Mon, 24 Feb 2014 11:13:11 -0500 Russell Bryant 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 out that we pret

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

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 incompatib

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

On Mon, 24 Feb 2014 07:56:19 -0800 Dan Smith 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 are largely

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

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 is

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

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

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

On Mon, 2014-02-24 at 20:22 +1030, Christopher Yeoh wrote: > On Mon, 24 Feb 2014 02:06:50 -0500 > Jay Pipes 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 > > > - Feat

  1   2   >