Open Stack

I attempted this in keystone as part of a very simple extension [1]. I understand that it is a much simpler case but nesting the Pecan within the existing routing infrastructure, rather than have a single Pecan app was fairly simple (though there are some limiting situations).

Any reason you decided to go this way rather than the one in my review? 

[1] https://review.openstack.org/#/c/62810/

----- Original Message -----
> From: "Ryan Petrello" <ryan.petrello at dreamhost.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Wednesday, 18 December, 2013 7:08:09 AM
> Subject: Re: [openstack-dev] [Nova] Support for Pecan in Nova
> 
> So any additional feedback on this patch?  I’d love to start working on
> porting some of the other extensions to pecan, but want to make sure I’ve
> got approval on this approach first.
> 
> https://review.openstack.org/#/c/61303/7
> 
> ---
> Ryan Petrello
> Senior Developer, DreamHost
> ryan.petrello at dreamhost.com
> 
> On Dec 14, 2013, at 10:45 AM, Doug Hellmann <doug.hellmann at dreamhost.com>
> wrote:
> 
> > 
> > 
> > 
> > On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh <cbkyeoh at gmail.com>
> > wrote:
> > 
> > On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann
> > <doug.hellmann at dreamhost.com> wrote:
> > That covers routes. What about the properties of the inputs and outputs?
> > 
> > 
> > I think the best way for me to describe it is that as the V3 API core and
> > all the extensions
> > are written, both the routes and input and output parameters are from a
> > client's perspective fixed at application
> > startup time. Its not an inherent restriction of the framework (an
> > extension could for
> > example dynamically load another extension at runtime if it really wanted
> > to), but we just don't do that.
> > 
> > OK, good.
> > 
> >  
> > 
> > Note that values of parameters returned can be changed by an extension
> > though. For example os-hide-server-addresses
> > can based on a runtime policy check and the vm_state of the server, filter
> > whether the values in the
> > addresses field are filtered out or not when returning information about a
> > server. This isn't a new thing in the
> > V3 API though, it already existed in the V2 API.
> > 
> > OK, it seems like as long as the fields are still present that makes the
> > API at least consistent for a given deployment's configuration.
> > 
> > Doug
> > 
> >  
> > 
> > Chris
> >  
> > 
> > On Fri, Dec 13, 2013 at 4:43 PM, Ryan Petrello
> > <ryan.petrello at dreamhost.com> wrote:
> > Unless there’s some other trickiness going on that I’m unaware of, the
> > routes for the WSGI app are defined at application startup time (by
> > methods called in the WSGI app’s __init__).
> > 
> > ---
> > Ryan Petrello
> > Senior Developer, DreamHost
> > ryan.petrello at dreamhost.com
> > 
> > On Dec 13, 2013, at 12:56 PM, Doug Hellmann <doug.hellmann at dreamhost.com>
> > wrote:
> > 
> > >
> > >
> > >
> > > On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh <cbkyeoh at gmail.com>
> > > wrote:
> > > On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes <jaypipes at gmail.com> wrote:
> > > On 12/11/2013 11:47 PM, Mike Perez wrote:
> > > 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
> > > <mailto:doug.hellmann at dreamhost.com>>wrote:
> > >
> > >
> > >
> > >
> > > On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
> > > ryan.petrello at dreamhost.com
> > > <mailto: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.
> > >
> > > +1. I agree with most of what Mike says above. The idea that there are
> > > core "extensions" in Nova's v3 API doesn't make a whole lot of sense to
> > > me.
> > >
> > >
> > > So would it help if we used the term "plugin" to talk about the framework
> > > that the API is implemented with,
> > > and extensions when talking about things which extend the core API? So
> > > the whole of the API is implemented
> > > using plugins, while the core plugins are not considered to be
> > > extensions.
> > >
> > > That distinction does help.
> > >
> > > Are the extensions enabled at startup time, or at runtime when an API
> > > call is made? That is, could 2 different users of the same cloud service
> > > instance see different fields in the value returned from the call
> > > because of some runtime decision made inside either an extension (where
> > > the extension might not add fields for some reason) or a bit of core
> > > code (by deciding not to call an extension at all)?
> > >
> > > Doug
> > > _______________________________________________
> > > 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
> > 
> > 
> > 
> > _______________________________________________
> > 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
>