Open Stack

On Mon, 2014-02-24 at 20:22 +1030, Christopher Yeoh wrote:
> 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.

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