On Mon, 2014-02-24 at 20:22 +1030, Christopher Yeoh wrote: > On Mon, 24 Feb 2014 02:06:50 -0500 > Jay Pipes <jaypi...@gmail.com> wrote: > > > On Mon, 2014-02-24 at 17:20 +1030, Christopher Yeoh wrote: > > > - Proposed way forward: > > > - Release the V3 API in Juno with nova-network and tasks support > > > - Feature freeze the V2 API when the V3 API is released > > > - Set the timeline for deprecation of V2 so users have a lot > > > of warning > > > - Fallback for those who really don't want to move after > > > deprecation is an API service which translates between V2 and V3 > > > requests, but removes the dual API support burden from Nova. > > > > And when do you think we can begin the process of deprecating the V3 > > API and removing API extensions and XML "translation" support? > > So did you mean V2 API here? I don't understand why you think the V3 > API would need deprecating any time soon.
No, I meant v3. > XML support has already been removed from the V3 API and I think the > patch to mark XML as deprecated for the V2 API and eventual removal in > Juno has already landed. So at least for part of the V2 API a one cycle > deprecation period has been seen as reasonable. OK, very sorry, I must have missed that announcement. I did not realize that XML support had already been removed from v3. > When it comes to API extensions I think that is actually more a > question of policy than anything else. The actual implementation behind > the scenes of a plugin architecture makes a lot of sense whether we > have extensions or not. An API extension is not a plugin. And I'm not arguing against a plugin architecture -- the difference is that a driver/plugin architecture enables a single public API to have difference backend implementations. Please see my diatribe on that here: https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg13660.html > It forces a good level of isolation between API > features and clarity of interaction where its needed - all of which > much is better from a maintenance point of view. Sorry, I have to violently disagree with you on that one. The API extensions (in Nova, Neutron, Keystone, et al) have muddied the code immeasurably and bled implementation into the public API -- something that is antithetical to good public API design. Drivers and plugins belong in the implementation layer. Not in the public API layer. > Now whether we have parts of the API which are optional or not is > really a policy decision as to whether we will force deployers to use > all of the plugins or a subset (eg currently the "core"). It's not about "forcing" providers to support all of the public API. It's about providing a single, well-documented, consistent HTTP REST API for *consumers* of that API. Whether a provider chooses to, for example, deploy with nova-network or Neutron, or Xen vs. KVM, or support block migration for that matter *should have no effect on the public API*. The fact that those choices currently *do* effect the public API that is consumed by the client is a major indication of the weakness of the API. > There is > the technical support for doing so in the V3 API (essentially what is > used to enforce the core of the API). And a major API version bump is > not required to change this. Perhaps this part falls in to the > DefCore discussions :-) I don't see how this discussion falls into the DefCore discussion. Best, -jay _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev