On Tue, 17 Mar 2015 15:56:27 +1300 Robert Collins <robe...@robertcollins.net> wrote:
> On 17 March 2015 at 14:27, Ken'ichi Ohmichi <ken1ohmi...@gmail.com> > wrote: > > >> 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 code. 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. Regards, Chris __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
