On Mon, 03 Mar 2014 12:32:04 -0500 Russell Bryant <rbry...@redhat.com> wrote:
> There has been quite a bit of discussion about the future of the v3 > API recently. There has been growing support for the idea that we > should change course and focus on evolving the existing v2 API > instead of putting out a new major revision. This message is a more > complete presentation of that proposal that concludes that we can do > what we really need to do with only the v2 API. > So one thing which I think is relevant to this discussion is that we are not comparing two theoretical paths. On one hand we have a v2 API related proposal which involves lot of backporting. I think there is a lack of appreciation in this proposal over how much effort would be involved to achieve this (and I don't think anyone is really putting their hand up to do the work required in the long term) as well as the risk involved in accidental changes to the V2 API. As a very rough guide of effort I think around 400+ patches have merged (not include copy/paste part 1 type patches) just in the Nova tree for the V3 API over Havana and Icehouse. This does not count the python novaclient or tempest support which would have to be implemented at some point to support an API changes which were backported. On the other hand we have the V3 API which with the exception of the nova-network support is almost complete and merged. And we have a much better idea of the effort as well as several people who want to and have the time to work on it as well as being willing to help reduce the dual maintenance overhead. To try to clarify what the V3 API would mean for users, developers and deployers I have put some information together here: http://ozlabs.org/~cyeoh/V3_API.html It also covers some approaches for reducing the dual maintenance issues in the short term and removing them in the long term. As well as a possible strategy for long term handling of significant API changes. Although having a V3 API does certainly involve some dual maintenance concerns about making internal Nova changes whilst supporting both the V2 and V3 API code. And so far in this discussion I don't think we have really managed to quantify what the dual maintenance overhead actually is (although the document above tries to). Also I don't think we should ignore the extra maintenance burdens discussed in in the linked document of attempting to evolve the V2 API and keep the old V2 API code base (which I think we may be able to separate conceptually from keeping support for the V2 API). Chris _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev