Sounds like what I’m hearing is “Let’s see something that uses this (that works)”? I’ll work on that :)
--- Ryan Petrello Senior Developer, DreamHost [email protected] On Dec 18, 2013, at 9:45 AM, Ryan Petrello <[email protected]> wrote: > Jamie: > > Your approach makes sense, but it still uses both pecan and Routes. One of > the goals of my patch was to (eventually) be able to remove the use of Routes > entirely in v3 for Nova once all of the extensions are re-implemented with > pecan (so that we’re not defining a mix of object dispatch and > regular-expression style routes). > > --- > Ryan Petrello > Senior Developer, DreamHost > [email protected] > > On Dec 18, 2013, at 6:05 AM, Jamie Lennox <[email protected]> wrote: > >> 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" <[email protected]> >>> To: "OpenStack Development Mailing List (not for usage questions)" >>> <[email protected]> >>> 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 >>> [email protected] >>> >>> On Dec 14, 2013, at 10:45 AM, Doug Hellmann <[email protected]> >>> wrote: >>> >>>> >>>> >>>> >>>> On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh <[email protected]> >>>> wrote: >>>> >>>> On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann >>>> <[email protected]> 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 >>>> <[email protected]> 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 >>>> [email protected] >>>> >>>> On Dec 13, 2013, at 12:56 PM, Doug Hellmann <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh <[email protected]> >>>>> wrote: >>>>> On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes <[email protected]> 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 >>>>> <[email protected] >>>>> <mailto:[email protected]>>wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello < >>>>> [email protected] >>>>> <mailto:[email protected]>> >>>>> 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 >>>>> [email protected] >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
