Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Christopher Yeoh]

So the short answer: as long as the api samples continue to generate
normally I don't think it will.

The long answer is more complicated. The V2 API documentation was generated
and updated manually.
We generate api samples for the documentation automatically but thats it.
I've been trying to improve on that
for V3 and have some experimental code here to add extra information along
with the api samples so
we can autogenerate the documentation entirely from what is generated in
the api sample directory. Kersten
Richter is working on what is required to convert from the api samples and
meta information into
wadl.

https://github.com/cyeoh/nova-v3-api-doc/tree/metafiles_2

But if it we're going to end up using wsme in J, perhaps its not worth
merging in Icehouse.

So for Icehouse its likely the documentation will either be generated
manually like the V2
or hopefully at least partially automated. But I don't think  Pecan will
change this (but I'd need to
see more examples of what the Pecan changes to the plugins actually look
like.

Regards,

Chris





On Thu, Dec 19, 2013 at 1:38 AM, Ryan Petrello
wrote:

> Additionally, can anyone here summarize the current status of v3
> documentation?  Is there a process I can currently run against Nova to
> generate a WADL (I want to make sure the Pecan changes work with it)?
>
> ---
> Ryan Petrello
> Senior Developer, DreamHost
> ryan.petre...@dreamhost.com
>
> On Dec 18, 2013, at 9:46 AM, Ryan Petrello 
> wrote:
>
> > 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 
> 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 
> 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" 
> >>>> 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  >
> >>>>> wrote:
> >>>>>
> >>>>> On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann
> >>>>>  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 

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Anne Gentle]

I replied on the review itself but here's what I know.

The v3 documentation is still underway, there's a long thread on the
openstack-docs list from October that should help explain the question's
base. Sounds like this patch does indeed affect the way docs are generated
potentially.

http://lists.openstack.org/pipermail/openstack-docs/2013-October/003081.html


On Wed, Dec 18, 2013 at 9:08 AM, Ryan Petrello
wrote:

> Additionally, can anyone here summarize the current status of v3
> documentation?  Is there a process I can currently run against Nova to
> generate a WADL (I want to make sure the Pecan changes work with it)?
>
> ---
> Ryan Petrello
> Senior Developer, DreamHost
> ryan.petre...@dreamhost.com
>
> On Dec 18, 2013, at 9:46 AM, Ryan Petrello 
> wrote:
>
> > 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 
> 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 
> 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" 
> >>>> 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  >
> >>>>> wrote:
> >>>>>
> >>>>> On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann
> >>>>>  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
> >>>>

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Ryan Petrello]

Additionally, can anyone here summarize the current status of v3 documentation? 
 Is there a process I can currently run against Nova to generate a WADL (I want 
to make sure the Pecan changes work with it)?

---
Ryan Petrello
Senior Developer, DreamHost
ryan.petre...@dreamhost.com

On Dec 18, 2013, at 9:46 AM, Ryan Petrello  wrote:

> 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  
> 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  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" 
>>>> To: "OpenStack Development Mailing List (not for usage questions)" 
>>>> 
>>>> 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 
>>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh 
>>>>> wrote:
>>>>> 
>>>>> On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann
>>>>>  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
>>>>>  wrote:
>>>>> Unless there’s some other trickiness going on that I’m unaware of, the
>>>>> routes for the WSGI app are defined at app

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Ryan Petrello]

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  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  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" 
>>> To: "OpenStack Development Mailing List (not for usage questions)" 
>>> 
>>> 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 
>>> wrote:
>>> 
>>>> 
>>>> 
>>>> 
>>>> On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh 
>>>> wrote:
>>>> 
>>>> On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann
>>>>  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
>>>>  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 
>>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh 
>>>>> wrote:
>>>>> On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes  wrote:
>>>>> On 12/11/2013 11:47 PM, Mike Perez wrote:
>>>>> On 10:06 Thu 12 Dec , Christopher Yeoh wrote:
>>>&

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Ryan Petrello]

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  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" 
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> 
>> 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 
>> wrote:
>> 
>>> 
>>> 
>>> 
>>> On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh 
>>> wrote:
>>> 
>>> On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann
>>>  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
>>>  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 
>>> wrote:
>>> 
>>>> 
>>>> 
>>>> 
>>>> On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh 
>>>> wrote:
>>>> On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes  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
>>>> >>> <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:
>>>> 
>>>> 
>&

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Alex Xu]

I replied some comments on the gerrit also. If we have patch for 
demonstrate pecan style extension, that will be great.


Thanks
Alex
On 2013年12月18日 05:08, Ryan Petrello wrote:

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  wrote:




On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh  wrote:

On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann  
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  
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  wrote:




On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh  wrote:
On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes  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
mailto:doug.hellm...@dreamhost.com>>wrote:




On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
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 exa

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Jamie Lennox]

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" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 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 
> wrote:
> 
> > 
> > 
> > 
> > On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh 
> > wrote:
> > 
> > On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann
> >  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
> >  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 
> > wrote:
> > 
> > >
> > >
> > >
> > > On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh 
> > > wrote:
> > > On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes  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
> > >  > > <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
> > >

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Christopher Yeoh]

Hi Ryan,

I've just replied with some comments on the changeset itself

Regards,

Chris


On Wed, Dec 18, 2013 at 7:38 AM, Ryan Petrello
wrote:

> 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 
> wrote:
>
> >
> >
> >
> > On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh 
> 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 
> wrote:
> >
> > >
> > >
> > >
> > > On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh 
> wrote:
> > > On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes  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
> > >  > > >wrote:
> > >
> > >
> > >
> > >
> > > On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
> > > 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 s

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Ryan Petrello]

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  wrote:

> 
> 
> 
> On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh  wrote:
> 
> On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann  
> 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  
> 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  
> wrote:
> 
> >
> >
> >
> > On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh  wrote:
> > On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes  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
> >  > >wrote:
> >
> >
> >
> >
> > On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
> > 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 sp

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Doug Hellmann]

On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh  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 
>>> wrote:
>>>
>>> >
>>> >
>>> >
>>> > On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh 
>>> wrote:
>>> > On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes  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
>>> > >> > >wrote:
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
>>> > 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 o

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Christopher Yeoh]

On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann
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.

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.

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 
>> wrote:
>>
>> >
>> >
>> >
>> > On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh 
>> wrote:
>> > On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes  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
>> > > > >wrote:
>> >
>> >
>> >
>> >
>> > On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
>> > 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 

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Doug Hellmann]

That covers routes. What about the properties of the inputs and outputs?


On Fri, Dec 13, 2013 at 4:43 PM, Ryan Petrello
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 
> wrote:
>
> >
> >
> >
> > On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh 
> wrote:
> > On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes  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
> >  > >wrote:
> >
> >
> >
> >
> > On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
> > 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

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Ryan Petrello]

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  wrote:

> 
> 
> 
> On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh  wrote:
> On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes  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
>  >wrote:
> 
> 
> 
> 
> On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
> 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 distinctio

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Jay Pipes]

On Fri, 2013-12-13 at 12:52 +1030, Christopher Yeoh wrote:
> On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes  wrote:

> 
> +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.

Yeah, that makes more sense :)

Best,
-jay



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

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Doug Hellmann]

On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh  wrote:

> On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes  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
 >>> >wrote:


>
>
>  On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
>> 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

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Christopher Yeoh]

On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes  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
>>> >> >wrote:
>>>
>>>


  On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
> 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.

Chris
___
OpenStack-dev mailing list
OpenStack-dev@li

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Christopher Yeoh]

On Fri, Dec 13, 2013 at 8:12 AM, Jonathan LaCour <
jonathan-li...@cleverdevil.org> wrote:

>
> On December 11, 2013 at 2:34:07 PM, Doug Hellmann (
> doug.hellm...@dreamhost.com) wrote:
>
> > On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello wrote:
> >
> > > 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?
>
> After taking a close look at how the API is constructed, I
> actually think that the current approach of having the API be
> defined purely through extensions is flawed, for a few reasons:
>
> 1. The code is extremely difficult to read and follow, because the API
>structure is entirely built at runtime based upon what is
>installed, rather than expressed declaratively in code.
>
>
So I'm too close to the code to have an unbiased opinion, but I found that
learning the V2 API code where parts of the API (core) were defined one way
and then extensions defined another even more confusing. Since they are
attempting
to achieve the same thing.

2. As a company providing a public cloud based upon OpenStack, with a
>desire to express compatibility with the "OpenStack API," its
>difficult to document the "standard" baseline Nova API. I shouldn't
>have to say "it depends" in API documentation.
>
>
The standard baseline for the Nova V3 API will be fixed. I think its a
decision higher up to
be made as to what is considered "OpenStack" but I'd be surprised if
OpenStack
compliant clouds were not permitted to add extra functionality to remain
compliant.


> 3. Based upon my read, extensions are in no way "quarantined" from the
>the baseline/standard/required API. In fact, they seem to be able
>to pollute the standard API with additional parameters and
>functionality. I can not envision a world in which this is sane.
>
> In my opinion, a well-designed and architected API should have the
> core functionality declaratively defined in the code itself, so as to
> give a good, well-documented, standard, and unchanging baseline. Then,
> an "extension" capability should be layered on in such a way that it
> doesn't alter the core API or serialized data.
>

Extensions can definitely add additional parameters and functionality and
that has been a pretty fundamental requirement for Nova development.
Perhaps this
will change as Nova matures, but at the moment we'd either have to stop new
features being added like being able to specify to a preserve_ephemeral
flag in rebuild
(just as one example happening in Icehouse), or have a major API version
every release.

Note that extensions are restricted to making only backwards compatible
changes
- eg behaviour has to stay the same if extra input parameters are not
present in a
request, and they can only add extra output parameters, they can't change
the value of
existing ones.


>
> Note: my opinion isn’t altered by the fact that some of the “core”
> API involves “required” extensions. The result is still difficult to
> read and document.
>
> That said, I don’t want to diminish or minimize the hard work that
> has been done on the V3 API thus far! Lots of thinking and heavy
> lifting has already been done, and its much appreciated. I am just
> concerned that we lost our way somewhere. Major API revisions only
> come along so often, and I’d prefer to raise my objections now
> rather than to hold them in and regret it!
>
>
So the idea of the V3 API originally came out of primarily wanting to clean
up many of the
warts, inconsistencies and bits of brokenness in the V2 API that we
couldn't because
of a requirement to keep backwards compatibility.  Perhaps in the future
Nova maturity
will reach the point where can start making guarantees like the core API is
never in anyway affected by extensions but I don't think we're there yet.

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

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Jonathan LaCour]

On December 11, 2013 at 2:34:07 PM, Doug Hellmann (doug.hellm...@dreamhost.com) 
wrote:

> On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello wrote:
> 
> > 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?

After taking a close look at how the API is constructed, I
actually think that the current approach of having the API be
defined purely through extensions is flawed, for a few reasons:

1. The code is extremely difficult to read and follow, because the API
   structure is entirely built at runtime based upon what is
   installed, rather than expressed declaratively in code.

2. As a company providing a public cloud based upon OpenStack, with a
   desire to express compatibility with the "OpenStack API," its
   difficult to document the "standard" baseline Nova API. I shouldn't
   have to say "it depends" in API documentation.

3. Based upon my read, extensions are in no way "quarantined" from the
   the baseline/standard/required API. In fact, they seem to be able
   to pollute the standard API with additional parameters and
   functionality. I can not envision a world in which this is sane.

In my opinion, a well-designed and architected API should have the
core functionality declaratively defined in the code itself, so as to
give a good, well-documented, standard, and unchanging baseline. Then,
an "extension" capability should be layered on in such a way that it
doesn't alter the core API or serialized data.

Note: my opinion isn’t altered by the fact that some of the “core” 
API involves “required” extensions. The result is still difficult to
read and document.

That said, I don’t want to diminish or minimize the hard work that
has been done on the V3 API thus far! Lots of thinking and heavy
lifting has already been done, and its much appreciated. I am just
concerned that we lost our way somewhere. Major API revisions only
come along so often, and I’d prefer to raise my objections now 
rather than to hold them in and regret it!

-- 
Jonathan LaCour



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

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Christopher Yeoh]

On Thu, Dec 12, 2013 at 3:17 PM, Mike Perez  wrote:

> On 10:06 Thu 12 Dec , Christopher Yeoh wrote:
> > On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann
> > wrote:
> >
> > 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.
>
> 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
>

Just to be clear, the deployer doesn't have to enable these, they are
enabled automatically,
but it will complain if a deployer attempts to disable them. Also anything
not core has a
"os-" prefix, while core plugins don't so it is easy to distinguish between
them. But yes I'd agree
that from a deployers point of view its not useful to talk about extensions
which have
to be enabled.

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

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Jay Pipes]

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
mailto:doug.hellm...@dreamhost.com>>wrote:






On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
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.


Best,
-jay

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

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Doug Hellmann]

On Wed, Dec 11, 2013 at 6:29 PM, Christopher Yeoh  wrote:

> On Thu, Dec 12, 2013 at 7:11 AM, Ryan Petrello <
> 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?
>>
>
> Yes, from an implementation view everything is an "extension", even core
> functionality. One issue with the V2 API is that because core is hard coded
> and separate from the plugin framework there were things you could do in
> core API code that you couldn't do in extensions and other things which you
> could do in both, but had to do in different ways. Which is bad from a
> maintainability/readability point of view. And inevitably we ended up with
> extension specific code sitting in what should have been only core code. So
> we ended up deciding to make everything a plugin to consistency of how API
> code is written and also ensured that the framework didn't treat core API
> code in any special way.
>

OK, I can completely see how that problem would lead to this solution.
I'll try to keep that in mind, and start thinking of "extension" in the way
it is actually used. :-)

Doug



>
>
>>
>> 2.  The approach in my review would allow us to translate extensions to
>> pecan piecemeal.  To me, this seems like a more desirable and manageable
>> approach than moving everything to pecan at once, given the scale of Nova’s
>> API.  Do others agree/disagree?  Until all v3 extensions are translated,
>> this means the v3 API is composed of two separate WSGI apps.
>>
>>
> Yes, I think this is the way to go. Attempting to get a big-bang patch
> merged would be rather challenging.
>
>
>
>> 3.  Can somebody explain the purpose of the wsgi.deserializer decorator?
>>  It’s something I’ve not accounted for yet in my pecan implementation.  Is
>> the goal to deserialize the request *body* from e.g., XML into a usable
>> data structure?  Is there an equivalent for JSON handling?  How does this
>> relate to the schema validation that’s being done in v3?
>>
>>
> Yes the deserializer decorator specifies and XML deserializer which is
> used when the default one is not suitable. schema validation is done on the
> deserialized output so essentially covers both JSON and XML (eg XML is not
> directly validated, but what we end up interpreting in the api code is).
>
> Chris
>
>
> ___
> 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

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Mike Perez]

On 10:06 Thu 12 Dec , Christopher Yeoh wrote:
> On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann
> wrote:
>
> >
> >
> >
> >> On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
> >> 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.


Thanks,
Mike Perez
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Alex Xu]

On 2013年12月12日 04:41, Ryan Petrello 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?

2.  The approach in my review would allow us to translate extensions to pecan 
piecemeal.  To me, this seems like a more desirable and manageable approach 
than moving everything to pecan at once, given the scale of Nova’s API.  Do 
others agree/disagree?  Until all v3 extensions are translated, this means the 
v3 API is composed of two separate WSGI apps.

+1 for this too.

3.  Can somebody explain the purpose of the wsgi.deserializer decorator?  It’s 
something I’ve not accounted for yet in my pecan implementation.  Is the goal 
to deserialize the request *body* from e.g., XML into a usable data structure?  
Is there an equivalent for JSON handling?  How does this relate to the schema 
validation that’s being done in v3?

---
Ryan Petrello
Senior Developer, DreamHost
ryan.petre...@dreamhost.com
___
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

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Christopher Yeoh]

On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann
wrote:

>
>
>
> On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
> 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.

Chris



> Doug
>
>
>
>>
>> 2.  The approach in my review would allow us to translate extensions to
>> pecan piecemeal.  To me, this seems like a more desirable and manageable
>> approach than moving everything to pecan at once, given the scale of Nova’s
>> API.  Do others agree/disagree?  Until all v3 extensions are translated,
>> this means the v3 API is composed of two separate WSGI apps.
>>
>> 3.  Can somebody explain the purpose of the wsgi.deserializer decorator?
>>  It’s something I’ve not accounted for yet in my pecan implementation.  Is
>> the goal to deserialize the request *body* from e.g., XML into a usable
>> data structure?  Is there an equivalent for JSON handling?  How does this
>> relate to the schema validation that’s being done in v3?
>>
>> ---
>> Ryan Petrello
>> Senior Developer, DreamHost
>> ryan.petre...@dreamhost.com
>> ___
>> 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

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Christopher Yeoh]

On Thu, Dec 12, 2013 at 7:11 AM, Ryan Petrello
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?
>

Yes, from an implementation view everything is an "extension", even core
functionality. One issue with the V2 API is that because core is hard coded
and separate from the plugin framework there were things you could do in
core API code that you couldn't do in extensions and other things which you
could do in both, but had to do in different ways. Which is bad from a
maintainability/readability point of view. And inevitably we ended up with
extension specific code sitting in what should have been only core code. So
we ended up deciding to make everything a plugin to consistency of how API
code is written and also ensured that the framework didn't treat core API
code in any special way.


>
> 2.  The approach in my review would allow us to translate extensions to
> pecan piecemeal.  To me, this seems like a more desirable and manageable
> approach than moving everything to pecan at once, given the scale of Nova’s
> API.  Do others agree/disagree?  Until all v3 extensions are translated,
> this means the v3 API is composed of two separate WSGI apps.
>
>
Yes, I think this is the way to go. Attempting to get a big-bang patch
merged would be rather challenging.



> 3.  Can somebody explain the purpose of the wsgi.deserializer decorator?
>  It’s something I’ve not accounted for yet in my pecan implementation.  Is
> the goal to deserialize the request *body* from e.g., XML into a usable
> data structure?  Is there an equivalent for JSON handling?  How does this
> relate to the schema validation that’s being done in v3?
>
>
Yes the deserializer decorator specifies and XML deserializer which is used
when the default one is not suitable. schema validation is done on the
deserialized output so essentially covers both JSON and XML (eg XML is not
directly validated, but what we end up interpreting in the api code is).

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

Re: [openstack-dev] [Nova] Support for Pecan in Nova

[Doug Hellmann]

On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello
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?

Doug



>
> 2.  The approach in my review would allow us to translate extensions to
> pecan piecemeal.  To me, this seems like a more desirable and manageable
> approach than moving everything to pecan at once, given the scale of Nova’s
> API.  Do others agree/disagree?  Until all v3 extensions are translated,
> this means the v3 API is composed of two separate WSGI apps.
>
> 3.  Can somebody explain the purpose of the wsgi.deserializer decorator?
>  It’s something I’ve not accounted for yet in my pecan implementation.  Is
> the goal to deserialize the request *body* from e.g., XML into a usable
> data structure?  Is there an equivalent for JSON handling?  How does this
> relate to the schema validation that’s being done in v3?
>
> ---
> Ryan Petrello
> Senior Developer, DreamHost
> ryan.petre...@dreamhost.com
> ___
> 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] [Nova] Support for Pecan in Nova

[Ryan Petrello]

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?

2.  The approach in my review would allow us to translate extensions to pecan 
piecemeal.  To me, this seems like a more desirable and manageable approach 
than moving everything to pecan at once, given the scale of Nova’s API.  Do 
others agree/disagree?  Until all v3 extensions are translated, this means the 
v3 API is composed of two separate WSGI apps.

3.  Can somebody explain the purpose of the wsgi.deserializer decorator?  It’s 
something I’ve not accounted for yet in my pecan implementation.  Is the goal 
to deserialize the request *body* from e.g., XML into a usable data structure?  
Is there an equivalent for JSON handling?  How does this relate to the schema 
validation that’s being done in v3?

---
Ryan Petrello
Senior Developer, DreamHost
ryan.petre...@dreamhost.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev