On 03/03/2014 08:14 AM, Steve Gordon wrote:
I would be interested in your opinion on the impact of a V2
version release which had backwards incompatibility in only one
area - and that is input validation. So only apps/SDKs which are
currently misusing the API (I think the most common problem would
be sending extraneous data which is currently ignored) would be
adversely affected. Other cases where where the API was used
correctly would be unaffected.
In this kind of scenario would we need to maintain the older V2
version where there is poor input validation as long? Or would the
V2 version with strong input validation be sufficient?
This is a tricky one because people who have applications or SDKs
that are misusing the API are unlikely to realize they are misusing
it until you actually make the switch to stricter validation by
default and they start getting errors back. We also don't as far as I
know have data at a deep enough level on exactly how people are using
the APIs to base a decision on - though perhaps some of the cloud
providers running OpenStack might be able to help here. I think at
best we'd be able to evaluate the common/well known SDKs to ensure
they aren't guilty (and if they are, to fix it) to gain some level of
confidence but suspect that breaking the API contract in this fashion
would still warrant a similar period of deprecation from the point of
view of distributors and cloud providers.
Would there be any point in doing it incrementally? Maybe initially the
command would still be accepted but it would print an error log
indicating that the command contained extraneous data.
That way someone could monitor the logs and see how much extraneous data
is being injected, but also contact the owner of the software and notify
them of the problem.
Chris
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
