Open Stack

On 10:06 Thu 12 Dec     , Christopher Yeoh wrote:
> On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann
> <doug.hellmann at dreamhost.com>wrote:
>
> >
> >
> >
> >> On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
> >> ryan.petrello at dreamhost.com> wrote:
> >
> >> Hello,
> >>
> >> I’ve spent the past week experimenting with using Pecan for Nova’s API,
> >> and have opened an experimental review:
> >>
> >> https://review.openstack.org/#/c/61303/6
> >>
> >> …which implements the `versions` v3 endpoint using pecan (and paves the
> >> way for other extensions to use pecan).  This is a *potential* approach
> >> I've considered for gradually moving the V3 API, but I’m open to other
> >> suggestions (and feedback on this approach).  I’ve also got a few open
> >> questions/general observations:
> >>
> >> 1.  It looks like the Nova v3 API is composed *entirely* of extensions
> >> (including “core” API calls), and that extensions and their routes are
> >> discoverable and extensible via installed software that registers
itself
> >> via stevedore.  This seems to lead to an API that’s composed of
installed
> >> software, which in my opinion, makes it fairly hard to map out the API
(as
> >> opposed to how routes are manually defined in other WSGI frameworks).
 I
> >> assume at this time, this design decision has already been solidified
for
> >> v3?
> >>
> >
> > Yeah, I brought this up at the summit. I am still having some trouble
> > understanding how we are going to express a stable core API for
> > compatibility testing if the behavior of the API can be varied so
> > significantly by deployment decisions. Will we just list each "required"
> > extension, and forbid any extras for a compliant cloud?
> >
>
> > Maybe the issue is caused by me misunderstanding the term "extension,"
> > which (to me) implies an optional component but is perhaps reflecting a
> > technical implementation detail instead?
> >
> >
> Yes and no :-) As Ryan mentions, all API code is a plugin in the V3 API.
> However, some must be loaded or the V3 API
> refuses to start up. In nova/api/openstack/__init__.py we have
> API_V3_CORE_EXTENSIONS which hard codes
> which extensions must be loaded and there is no config option to override
> this (blacklisting a core plugin will result in the
> V3 API not starting up).
>
> So for compatibility testing I think what will probably happen is that
> we'll be defining a minimum set (API_V3_CORE_EXTENSIONS)
> that must be implemented and clients can rely on that always being present
> on a compliant cloud. But clients can also then query through /extensions
> what other functionality (which is backwards compatible with respect to
> core) may also be present on that specific cloud.

This really seems similar to the idea of having a router class, some
controllers and you map them. From my observation at the summit, calling
everything an extension creates confusion. An extension "extends" something.
For example, Chrome has extensions, and they extend the idea of the core
features of a browser. If you want to do more than back/forward, go to an
address, stop, etc, that's an extension. If you want it to play an audio
clip
"stop, hammer time" after clicking the stop button, that's an example of an
extension.

In OpenStack, we use extensions to extend core. Core are the essential
feature(s) of the project. In Cinder for example, core is volume. In core
you
can create a volume, delete a volume, attach a volume, detach a volume,
etc. If
you want to go beyond that, that's an extension. If you want to do volume
encryption, that's an example of an extension.

I'm worried by the discrepancies this will create among the programs. You
mentioned maintainability being a plus for this. I don't think it'll be
great
from the deployers perspective when you have one program that thinks
everything
is an extension and some of them have to be enabled that the deployer has
to be
mindful of, while the rest of the programs consider all extensions to be
optional.


Thanks,
Mike Perez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131211/1b1fa52f/attachment.html>