Open Stack

On Mon, 24 Feb 2014 02:06:50 -0500
Jay Pipes <jaypipes at 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.

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.

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. 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.

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"). 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 :-)

Chris