----- Original Message ----- > Hi Steve, > > On Sat, 1 Mar 2014 16:14:19 -0500 (EST) > Steve Gordon <[email protected]> wrote:
[SNIP] > > My feeling both with my product hat and my upstream documentation > > contributor hat on knowing some of the issues we've had there in the > > past is that one release cycle of deprecation for v2 would not be > > enough notice for this kind of change, particularly if it's also a > > cycle where v3 is still being pretty actively worked on and a moving > > target for the rest of the ecosystem (which it looks like will be the > > case for Juno, if we continue in the direction of doing v3). > > Thank you to you and everyone else for their feedback around this. With > the exception of XML deprecation I don't think anyone was considering a > single cycle for deprecation for V2 would be reasonable. But numbers > around how long would be reasonable would be helpful to guide as to > what path we take. Right, I just wanted to note that explicitly. It was pointed out elsewhere in the thread that decisions on when to mark v2 deprecated, and later when to actually remove it, should probably be based on readiness criteria rather than time-based which makes sense. I still think a time-based *minimum* period between deprecation and removal makes sense for the reasons I stated above - beyond that a criteria-based evaluation would still apply (I guess effectively I'm saying here that one of the criteria for v2 removal should be X cycles of deprecation for people to update consuming apps etc.). Additional criteria I think are important are support for v3 from other OpenStack projects that interact with Nova via the API (including the clients), and support in the most common SDKs (this is I recognize a sticky one because then you are blocking on changes that aren't necessarily to OpenStack projects). These would seem obvious but don't seem to have been nailed in some previous API bumps within OpenStack. > 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. Thanks, Steve _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
