On Thu, Feb 20, 2014 at 7:10 AM, Sean Dague <s...@dague.net> wrote: > On 02/20/2014 09:55 AM, Christopher Yeoh wrote: >> On Thu, 20 Feb 2014 08:22:57 -0500 >> Sean Dague <s...@dague.net> wrote: >>> >>> We're also duplicating a lot of test and review energy in having 2 API >>> stacks. Even before v3 has come out of experimental it's consumed a >>> huge amount of review resource on both the Nova and Tempest sides to >>> get it to it's current state. >>> >>> So my feeling is that in order to get more energy and focus on the >>> API, we need some kind of game plan to get us to a single API >>> version, with a single data payload in L (or on the outside, M). If >>> the decision is v2 must be in both those releases (and possibly >>> beyond), then it seems like asking other hard questions. >>> >>> * why do a v3 at all? instead do we figure out a way to be able to >>> evolve v2 in a backwards compatible way. >> >> So there's lots of changes (cleanups) made between v2 and v3 which are >> really not possible to do in a backwards compatible way. One example >> is that we're a lot stricter and consistent on input validation in v3 >> than v2 which is better both from a user and server point of view. >> Another is that the tasks API would be a lot uglier and really look >> "bolted on" if we tried to do so. Also doing so doesn't actually reduce >> the test load as if we're still supporting the old 'look' of the api we >> still need to test for it separately to the new 'look' even if we don't >> bump the api major version. >> >> In terms of code sharing (and we've experimented a bit with this for >> v2/v3) I think in most cases ends up actually being easier having two >> quite completely separate trees because it ends up diverging so much >> that having if statements around everywhere to handle the different >> cases is actually a higher maintenance burden (much harder to read) >> than just knowing that you might have to make changes in two quite >> separate places. >> >>> * if we aren't doing a v3, can we deprecate XML in v2 in Icehouse so >>> that working around all that code isn't a velocity inhibitor in the >>> cleanups required in v2? Because some of the crazy hacks that exist to >>> make XML structures work for the json in v2 is kind of special. >> >> So I don't think we can do that for similar reasons we can't just drop >> V2 after a couple of cycles. We should be encouraging people off, not >> forcing them off. >> >>> This big bang approach to API development may just have run it's >>> course, and no longer be a useful development model. Which is good to >>> find out. Would have been nice to find out earlier... but not all >>> lessons are easy or cheap. :) >> >> So I think what the v3 gives us is much more consistent and clean >> API base to start from. It's a clean break from the past. But we have to >> be much more careful about any future API changes/enhancements than we >> traditionally have done in the past especially with any changes which >> affect the core. I think we've already significantly raised the quality >> bar in what we allow for both v2 and v3 in Icehouse compared to previous >> releases (those frustrated with trying to get API changes in will >> probably agree) but I'd like us to get even stricter about it in the >> future because getting it wrong in the API design has a MUCH higher >> long term impact than bugs in most other areas. Requiring an API spec >> upfront (and reviewing it) with a blueprint for any new API features >> should IMO be compulsory before a blueprint is approved. >> >> Also micro and extension versioning is not the magic bullet which will >> get us out of trouble in the future. Especially with the core changes. >> Because even though versioning allows us to make changes, for similar >> reasons to not being able to just drop V2 after a couple of cycles >> we'll still need to keep supporting (and testing) the old behaviour for >> a significant period of time (we have often quietly ignored >> this issue in the past). >> >> Ultimately the only way to free ourselves from the maintenance of two >> API versions (and I'll claim this is rather misleading as it actually >> has more dimensions to it than this) is to convince users to move from >> the V2 API to the "new one". And it doesn't make much difference >> whether we call it V3 or V2.1 we still have very similar maintenance >> burdens if we want to make the sorts of API changes that we have done >> for V3. > > I want to flip this a little bit around. As an API consumer for an > upstream service I actually get excited when they announce a new version > and give me some new nobs to play with. Often times I'll even email > providers asking for certain API interfaces get exposed. > > I do think we need to actually start from the end goal and work > backwards. My assumption is that 1 API vs. with 1 Data Format in L/M is > our end goal. I think that there are huge technical debt costs with > anything else. Our current course and speed makes us have 3 APIs/Formats > in that time frame.
++, I think 1 API in L/M is a great goal > > There is no easy way out of this, but I think that the current course > and speed inhibits us in a lot of ways, not least of which is the > ability to get more people active in this part of Nova to help out. > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
