So I've been playing with microversions and noticed that the information about
req.ver_obj.matches(start_version, end_version) in the spec doesn't actually
match what's in the codebase.
1) The code has req.api_version_request instead of req.ver_obj
2) The spec says that "end_version is option
FWIW I think we need to consider that the API is completely froxen for the
V2 API (so this freeze does not apply to v2.1 microversions) except under
very serious circumstances and only very high priority bug fixes and only
apply this to a suitable microversion bump. We really want to get rid of
the
On Thu, Mar 12, 2015 at 11:19 PM, Christopher Yeoh
wrote:
> On Wed, 11 Mar 2015 09:32:11 -0600
> Chris Friesen wrote:
>
> >
> > Hi,
> >
> > I'm working on bug #1420848 which addresses the issue that doing a
> > "service-disable" followed by a "service-enable" against a "down"
> > compute node wi
CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
From: Chris Friesen
To:
Date: 03/11/2015 11:44 PM
Subject:Re: [openstack-dev] [nova] need input on possible
01 PM---Hi, I'm working on bug #1420848 which addresses the issue that
doing a
From: Chris Friesen
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 03/11/2015 04:35 PM
Subject: [openstack-dev] [nova] need input on possibl
lding, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
From: Chris Friesen
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 03/11/2015 04:35 PM
Subject: [openstack-dev] [nova] need input on possible API change for
Hi,
I'm working on bug #1420848 which addresses the issue that doing a
"service-disable" followed by a "service-enable" against a "down" compute node
will result in the compute node going "up" for a while, possibly causing delays
to operations that try to schedule on that compute node.
The
