On 2015年03月17日 13:31, Christopher Yeoh wrote:
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.
+1, v2.1 should be the future
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
__________________________________________________________________________
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
