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
ryan.petre...@dreamhost.com

On Dec 18, 2013, at 9:45 AM, Ryan Petrello <ryan.petre...@dreamhost.com> 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
> ryan.petre...@dreamhost.com
> 
> On Dec 18, 2013, at 6:05 AM, Jamie Lennox <jamielen...@redhat.com> 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" <ryan.petre...@dreamhost.com>
>>> To: "OpenStack Development Mailing List (not for usage questions)" 
>>> <openstack-dev@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.petre...@dreamhost.com
>>> 
>>> On Dec 14, 2013, at 10:45 AM, Doug Hellmann <doug.hellm...@dreamhost.com>
>>> wrote:
>>> 
>>>> 
>>>> 
>>>> 
>>>> On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh <cbky...@gmail.com>
>>>> wrote:
>>>> 
>>>> On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann
>>>> <doug.hellm...@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.petre...@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.petre...@dreamhost.com
>>>> 
>>>> On Dec 13, 2013, at 12:56 PM, Doug Hellmann <doug.hellm...@dreamhost.com>
>>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh <cbky...@gmail.com>
>>>>> wrote:
>>>>> On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes <jaypi...@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.hellm...@dreamhost.com
>>>>> <mailto:doug.hellm...@dreamhost.com>>wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
>>>>> ryan.petre...@dreamhost.com
>>>>> <mailto:ryan.petre...@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@lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> 
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to