- 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
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
- 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
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
-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
-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
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
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
: [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
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
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
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
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
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:
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
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
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
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:
, 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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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:
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
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
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
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)
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
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
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
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
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
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
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
+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?
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,
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
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
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
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,
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
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
-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
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
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
- 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
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
-
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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.
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
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.
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
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
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
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”
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
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
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,
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
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,
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
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
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
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
-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
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
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
96 matches
Mail list logo
