[openstack-dev] [nova] what is our shipped paste.ini going to be for Kilo
cbkyeoh at gmail.com
Tue Mar 17 05:31:02 UTC 2015
On Tue, 17 Mar 2015 15:56:27 +1300
Robert Collins <robertc at robertcollins.net> wrote:
> On 17 March 2015 at 14:27, Ken'ichi Ohmichi <ken1ohmichi at gmail.com>
> >> I am worried about SDKs making requests that have additional JSON
> >> attributes that were previously ignored by v2, but will be
> >> considered invalid by the v2.1 validation code. If we were to just
> >> strip out the extra items, rather than error out the request (when
> >> you don't specify a microversion), I would be less worried about
> >> the transition. Maybe that what we do?
> > Nice point.
> > That is a main difference in API behaviors between v2 and v2.1 APIs.
> > If SDKs pass additional JSON attributes to Nova API now, developers
> > need to fix/remove these attributes because that is a bug on SDKs
> > side.
> > These attributes are unused and meaningless, so some APIs of SDKs
> > would contain problems if passing this kind of attributes.
> > Sometime it was difficult to know what are available attributes
> > before v2.1 API, so "The full monty approach" will clarify problems
> > of SDKs and make SDKs' quality better.
> > Thanks
> > Ken Ohmichi
> Better at the cost of forcing all existing users to upgrade just to
> keep using code of their own that already worked.
> Not really 'better' IMO. Different surely.
> We could (should) add Warning: headers to inform about this, but
> breaking isn't healthy IMO.
It'd be up to the operators, but there is always the option of simply
editing the paste.ini file so /v2 is again the produced by the old v2
My main concern about v2 / v2.1 compatibility in practicce (rather than
just passing the same tempest and uniteststs which does work) is lack
of feedback. Probably don't exepct positive feedback in many cases but
we're not really getting negative feedback much either. I really would
appreciate people actually trying it more real world apps so we get a
better idea of the compatibility in areas of the code that don't have
good tempest coverage or have unitests which are incomplete.
More information about the OpenStack-dev