On Fri, 21 Mar 2014 12:00:00 +0100
Thierry Carrez wrote:
> >
> > But we certainly don't want to end up in the situation of trying to
> > work out how to rollback two backwards incompatible API changes.
>
> My vote still goes to reverting, for all the reasons Chris just
> exposed. I could live w
On Fri, 21 Mar 2014 13:34:08 -0400
David Kranz wrote:
> On 03/21/2014 05:04 AM, Christopher Yeoh wrote:
> Nope. IMO we should just accept that an incompatible change was made
> that should not have been, revert it, and move on. I hope that saying
> our code base is going to support CD does not
On Fri, 21 Mar 2014 07:57:34 -0600
Chris Friesen wrote:
> This is sort of off on a tangent, but one of the things that resulted
> in this being a problem was the fact that if someone creates a
> private flavor and then tries to add access second flavor access call
> will fail because the the tenan
On 03/21/2014 02:18 PM, Chris Behrens wrote:
FWIW, I'm fine with any of the options posted. But I'm curious about
the precedence that reverting would create. It essentially sounds like
if we release a version with an API bug, the bug is no longer a bug in
the API and the bug becomes a bug in
FWIW, I’m fine with any of the options posted. But I’m curious about the
precedence that reverting would create. It essentially sounds like if we
release a version with an API bug, the bug is no longer a bug in the API and
the bug becomes a bug in the documentation. The only way to ‘fix' the AP
On 03/21/2014 05:04 AM, Christopher Yeoh wrote:
On Thu, 20 Mar 2014 15:45:11 -0700
Dan Smith wrote:
I know that our primary delivery mechanism is releases right now, and
so if we decide to revert before this gets into a release, that's
cool. However, I think we need to be looking at CD as a ver
On Fri, Mar 21, 2014 at 2:04 AM, Christopher Yeoh wrote:
> On Thu, 20 Mar 2014 15:45:11 -0700
> Dan Smith wrote:
> >
> > I know that our primary delivery mechanism is releases right now, and
> > so if we decide to revert before this gets into a release, that's
> > cool. However, I think we need
This is sort of off on a tangent, but one of the things that resulted in
this being a problem was the fact that if someone creates a private
flavor and then tries to add access second flavor access call will fail
because the the tenant already is on the access list.
Something I was wondering..
On 2014年03月21日 17:04, Christopher Yeoh wrote:
On Thu, 20 Mar 2014 15:45:11 -0700
Dan Smith wrote:
I know that our primary delivery mechanism is releases right now, and
so if we decide to revert before this gets into a release, that's
cool. However, I think we need to be looking at CD as a very
Christopher Yeoh wrote:
> I don't want to cause issues for the CD people, but perhaps it won't be
> too disruptive for them (some direct feedback would be handy). The
> initial backwards incompatible change did not result in any bug reports
> coming back to us at all. If there were lots of users us
On Thu, 20 Mar 2014 15:45:11 -0700
Dan Smith wrote:
>
> I know that our primary delivery mechanism is releases right now, and
> so if we decide to revert before this gets into a release, that's
> cool. However, I think we need to be looking at CD as a very important
> use-case and I don't want to
On Thu, 20 Mar 2014 14:31:43 -0700
Joe Gordon wrote:
> On Wed, Mar 19, 2014 at 5:54 PM, Christopher Yeoh
> wrote:
>
> > Hi,
> >
> > So it turns out that we have made a backwards incompatible change to
> > the V2 API in Icehouse. Previously when creating a private flavor
> > access was not autom
> If we managed to break Horizon, its likely we've broken (or will break)
> other people's scripts or SDKs.
>
> The patch was merged in October (just after Icehouse opened) and so has
> been used in clouds that do CD for quite a while. After some discussion
> on IRC I think we'll end up having to
On Wed, Mar 19, 2014 at 5:54 PM, Christopher Yeoh wrote:
> Hi,
>
> So it turns out that we have made a backwards incompatible change to
> the V2 API in Icehouse. Previously when creating a private flavor
> access was not automatically given to the tenant, now it is. The
> documentation has always
On Thu, Mar 20, 2014 at 3:51 AM, Thierry Carrez wrote:
> Christopher Yeoh wrote:
> > The patch was merged in October (just after Icehouse opened) and so has
> > been used in clouds that do CD for quite a while. After some discussion
> > on IRC I think we'll end up having to leave this backwards in
Sorry if my meaning was unclear. I think we should revert as well.
Best Regards,
Solly Ross
- Original Message -
From: "David Kranz"
To: openstack-dev@lists.openstack.org
Sent: Thursday, March 20, 2014 2:20:42 PM
Subject: Re: [openstack-dev] [nova] Backwards incompatible A
20, 2014 6:51:26 AM
Subject: Re: [openstack-dev] [nova] Backwards incompatible API changes
Christopher Yeoh wrote:
The patch was merged in October (just after Icehouse opened) and so has
been used in clouds that do CD for quite a while. After some discussion
on IRC I think we'll end up havin
o to speak, whereas people using
versioned releases are less likely to be as flexible.
Best Regards,
Solly Ross
- Original Message -
From: "Thierry Carrez"
To: openstack-dev@lists.openstack.org
Sent: Thursday, March 20, 2014 6:51:26 AM
Subject: Re: [openstack-dev] [nova] Backwa
On Thu, 20 Mar 2014 11:51:26 +0100
Thierry Carrez wrote:
>
> I still think reverting before release is an option we should
> consider. My point is, yes we broke it back in October for people
> doing CD (and they might by now have gotten used to it), if we let
> this to release we'll then break it
Christopher Yeoh wrote:
> The patch was merged in October (just after Icehouse opened) and so has
> been used in clouds that do CD for quite a while. After some discussion
> on IRC I think we'll end up having to leave this backwards incompatible
> change in there - given there are most likely users
Hi,
So it turns out that we have made a backwards incompatible change to
the V2 API in Icehouse. Previously when creating a private flavor
access was not automatically given to the tenant, now it is. The
documentation has always said that it was, but we lied.
https://review.openstack.org/#/c/408
21 matches
Mail list logo
