Open Stack

On Mon, Jan 13, 2014 at 11:15 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> On Mon, 2014-01-13 at 09:40 -0500, Ryan Petrello wrote:
> > Jay, I’ll +1 to that.  As I’ve been tinkering with potential Pecan
> support for the Nova API, I’ve run into the same issue w/ the API
> composition being seriously complicated (to the point where I’ve realized
> Pecan isn’t the hard part, it’s the bunch of cruft you need to tie in
> Pecan/Routes/Falcon/<fill in WSGI framework here>).
>
> Indeed. And don't get me wrong... I'm not at all saying that Chris is to
> blame for anything (or any one person in particular). Just pointing out
> that, IMO, the usefulness of API extensions is outweighed by the added
> complexity and churn that they bring with them.
>
>
So whilst not supporting API extensions would make things simpler for us,
it does have some implications.

We have around 50+ plugins and only slightly more than 10 are considered to
be "core". So with a static API we'd have to have what I think would be a
pretty long discussion about what functionality we will no longer support,
and inevitably we'll end up with a much larger subset of existing
functionality that all Openstack deployers would have to support. Including
perhaps all the backend requirements as having an API which doesn't
actually work is I don't think an improvement for client programs on not
offering the API functionality for a deployment in the first place.

The other issue is how often with a static API we would have to do version
bumping. Icehouse is not unique in having the Nova API extended in several
areas and I doubt Juno would be any different. So I expect even if we
decided we could simply say "no" to new features more often, with a static
API we'll be releasing a new API version every release for the forseable
future - what sort of impact does that have on deployers and users?

I think this effect is magnified with continuous deployment. With a static
API and no ability to not immediately deploy an extension just merged, do
they have to have an API version bump every time an API changing patch
lands?

And although we don't really have an official policy around it, I think the
API extension functionality has been used as a way of allowing new
functionality into Nova and evaluating it in place before deciding whether
or not it becomes a core part of Nova.

Chris



> -jay
>
> > ---
> > Ryan Petrello
> > Senior Developer, DreamHost
> > ryan.petrello at dreamhost.com
> >
> > On Jan 13, 2014, at 9:23 AM, Jay Pipes <jaypipes at gmail.com> wrote:
> >
> > > On Sun, 2014-01-12 at 19:52 -0800, Christopher Yeoh wrote:
> > >> On my phone so will be very brief but perhaps the extensions extension
> > >> could publish the jsonschema(s) for the extension. I think the only
> > >> complicating  factor would be where extensions extend extensions but I
> > >> think it's all doable.
> > >
> > > Am I the only one that sees the above statement as another indication
> of
> > > why API extensions should eventually find their way into the dustbin of
> > > OpenStack history?
> > >
> > > -jay
> > >
> > >
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140114/dec3f055/attachment.html>