Open Stack

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.petrello at dreamhost.com

On Dec 18, 2013, at 9:46 AM, Ryan Petrello <ryan.petrello at dreamhost.com> 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.petrello at dreamhost.com
> 
> On Dec 18, 2013, at 9:45 AM, Ryan Petrello <ryan.petrello at dreamhost.com> wrote:
> 
>> Jamie:
>> 
>> Your approach makes sense, but it still uses both pecan and Routes.  One of the goals of my patch was to (eventually) be able to remove the use of Routes entirely in v3 for Nova once all of the extensions are re-implemented with pecan (so that we’re not defining a mix of object dispatch and regular-expression style routes).
>> 
>> ---
>> Ryan Petrello
>> Senior Developer, DreamHost
>> ryan.petrello at dreamhost.com
>> 
>> On Dec 18, 2013, at 6:05 AM, Jamie Lennox <jamielennox at redhat.com> wrote:
>> 
>>> I attempted this in keystone as part of a very simple extension [1]. I understand that it is a much simpler case but nesting the Pecan within the existing routing infrastructure, rather than have a single Pecan app was fairly simple (though there are some limiting situations).
>>> 
>>> Any reason you decided to go this way rather than the one in my review? 
>>> 
>>> [1] https://review.openstack.org/#/c/62810/
>>> 
>>> ----- Original Message -----
>>>> From: "Ryan Petrello" <ryan.petrello at dreamhost.com>
>>>> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
>>>> Sent: Wednesday, 18 December, 2013 7:08:09 AM
>>>> Subject: Re: [openstack-dev] [Nova] Support for Pecan in Nova
>>>> 
>>>> So any additional feedback on this patch?  I’d love to start working on
>>>> porting some of the other extensions to pecan, but want to make sure I’ve
>>>> got approval on this approach first.
>>>> 
>>>> https://review.openstack.org/#/c/61303/7
>>>> 
>>>> ---
>>>> Ryan Petrello
>>>> Senior Developer, DreamHost
>>>> ryan.petrello at dreamhost.com
>>>> 
>>>> On Dec 14, 2013, at 10:45 AM, Doug Hellmann <doug.hellmann at dreamhost.com>
>>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh <cbkyeoh at gmail.com>
>>>>> wrote:
>>>>> 
>>>>> On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann
>>>>> <doug.hellmann at dreamhost.com> wrote:
>>>>> That covers routes. What about the properties of the inputs and outputs?
>>>>> 
>>>>> 
>>>>> I think the best way for me to describe it is that as the V3 API core and
>>>>> all the extensions
>>>>> are written, both the routes and input and output parameters are from a
>>>>> client's perspective fixed at application
>>>>> startup time. Its not an inherent restriction of the framework (an
>>>>> extension could for
>>>>> example dynamically load another extension at runtime if it really wanted
>>>>> to), but we just don't do that.
>>>>> 
>>>>> OK, good.
>>>>> 
>>>>> 
>>>>> 
>>>>> Note that values of parameters returned can be changed by an extension
>>>>> though. For example os-hide-server-addresses
>>>>> can based on a runtime policy check and the vm_state of the server, filter
>>>>> whether the values in the
>>>>> addresses field are filtered out or not when returning information about a
>>>>> server. This isn't a new thing in the
>>>>> V3 API though, it already existed in the V2 API.
>>>>> 
>>>>> OK, it seems like as long as the fields are still present that makes the
>>>>> API at least consistent for a given deployment's configuration.
>>>>> 
>>>>> Doug
>>>>> 
>>>>> 
>>>>> 
>>>>> Chris
>>>>> 
>>>>> 
>>>>> On Fri, Dec 13, 2013 at 4:43 PM, Ryan Petrello
>>>>> <ryan.petrello at dreamhost.com> wrote:
>>>>> Unless there’s some other trickiness going on that I’m unaware of, the
>>>>> routes for the WSGI app are defined at application startup time (by
>>>>> methods called in the WSGI app’s __init__).
>>>>> 
>>>>> ---
>>>>> Ryan Petrello
>>>>> Senior Developer, DreamHost
>>>>> ryan.petrello at dreamhost.com
>>>>> 
>>>>> On Dec 13, 2013, at 12:56 PM, Doug Hellmann <doug.hellmann at dreamhost.com>
>>>>> wrote:
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh <cbkyeoh at gmail.com>
>>>>>> wrote:
>>>>>> On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes <jaypipes at gmail.com> wrote:
>>>>>> On 12/11/2013 11:47 PM, Mike Perez wrote:
>>>>>> On 10:06 Thu 12 Dec     , Christopher Yeoh wrote:
>>>>>> On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann
>>>>>> <doug.hellmann at dreamhost.com
>>>>>> <mailto:doug.hellmann at dreamhost.com>>wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
>>>>>> ryan.petrello at dreamhost.com
>>>>>> <mailto:ryan.petrello at dreamhost.com>>
>>>>>> wrote:
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> I’ve spent the past week experimenting with using Pecan for
>>>>>> Nova’s
>>>>>> API
>>>>>> and have opened an experimental review:
>>>>>> 
>>>>>> 
>>>>>> https://review.openstack.org/#/c/61303/6
>>>>>> 
>>>>>> …which implements the `versions` v3 endpoint using pecan (and
>>>>>> paves the
>>>>>> way for other extensions to use pecan).  This is a *potential*
>>>>>> 
>>>>>> approach
>>>>>> I've considered for gradually moving the V3 API, but I’m open
>>>>>> to other suggestions (and feedback on this approach).  I’ve
>>>>>> also got a few open questions/general observations:
>>>>>> 
>>>>>> 1.  It looks like the Nova v3 API is composed *entirely* of
>>>>>> extensions (including “core” API calls), and that extensions
>>>>>> and their routes are discoverable and extensible via installed
>>>>>> software that registers
>>>>>> itself
>>>>>> via stevedore.  This seems to lead to an API that’s composed of
>>>>>> 
>>>>>> installed
>>>>>> software, which in my opinion, makes it fairly hard to map out
>>>>>> the
>>>>>> API (as
>>>>>> opposed to how routes are manually defined in other WSGI
>>>>>> frameworks).  I
>>>>>> assume at this time, this design decision has already been
>>>>>> solidified for
>>>>>> v3?
>>>>>> 
>>>>>> 
>>>>>> Yeah, I brought this up at the summit. I am still having some
>>>>>> trouble understanding how we are going to express a stable core
>>>>>> API for compatibility testing if the behavior of the API can be
>>>>>> varied so significantly by deployment decisions. Will we just
>>>>>> list each
>>>>>> "required"
>>>>>> extension, and forbid any extras for a compliant cloud?
>>>>>> 
>>>>>> 
>>>>>> Maybe the issue is caused by me misunderstanding the term
>>>>>> "extension," which (to me) implies an optional component but is
>>>>>> perhaps reflecting a technical implementation detail instead?
>>>>>> 
>>>>>> 
>>>>>> Yes and no :-) As Ryan mentions, all API code is a plugin in the V3
>>>>>> API. However, some must be loaded or the V3 API refuses to start
>>>>>> up. In nova/api/openstack/__init__.py we have
>>>>>> API_V3_CORE_EXTENSIONS which hard codes which extensions must be
>>>>>> loaded and there is no config option to override this (blacklisting
>>>>>> a core plugin will result in the V3 API not starting up).
>>>>>> 
>>>>>> So for compatibility testing I think what will probably happen is
>>>>>> that we'll be defining a minimum set (API_V3_CORE_EXTENSIONS) that
>>>>>> must be implemented and clients can rely on that always being
>>>>>> present
>>>>>> on a compliant cloud. But clients can also then query through
>>>>>> /extensions what other functionality (which is backwards compatible
>>>>>> with respect to core) may also be present on that specific cloud.
>>>>>> 
>>>>>> This really seems similar to the idea of having a router class, some
>>>>>> controllers and you map them. From my observation at the summit,
>>>>>> calling everything an extension creates confusion. An extension
>>>>>> "extends" something. For example, Chrome has extensions, and they
>>>>>> extend the idea of the core features of a browser. If you want to do
>>>>>> more than back/forward, go to an address, stop, etc, that's an
>>>>>> extension. If you want it to play an audio clip "stop, hammer time"
>>>>>> after clicking the stop button, that's an example of an extension.
>>>>>> 
>>>>>> In OpenStack, we use extensions to extend core. Core are the
>>>>>> essential feature(s) of the project. In Cinder for example, core is
>>>>>> volume. In core you can create a volume, delete a volume, attach a
>>>>>> volume, detach a volume, etc. If you want to go beyond that, that's
>>>>>> an extension. If you want to do volume encryption, that's an example
>>>>>> of an extension.
>>>>>> 
>>>>>> I'm worried by the discrepancies this will create among the programs.
>>>>>> You mentioned maintainability being a plus for this. I don't think
>>>>>> it'll be great from the deployers perspective when you have one
>>>>>> program that thinks everything is an extension and some of them have
>>>>>> to be enabled that the deployer has to be mindful of, while the rest
>>>>>> of the programs consider all extensions to be optional.
>>>>>> 
>>>>>> +1. I agree with most of what Mike says above. The idea that there are
>>>>>> core "extensions" in Nova's v3 API doesn't make a whole lot of sense to
>>>>>> me.
>>>>>> 
>>>>>> 
>>>>>> So would it help if we used the term "plugin" to talk about the framework
>>>>>> that the API is implemented with,
>>>>>> and extensions when talking about things which extend the core API? So
>>>>>> the whole of the API is implemented
>>>>>> using plugins, while the core plugins are not considered to be
>>>>>> extensions.
>>>>>> 
>>>>>> That distinction does help.
>>>>>> 
>>>>>> Are the extensions enabled at startup time, or at runtime when an API
>>>>>> call is made? That is, could 2 different users of the same cloud service
>>>>>> instance see different fields in the value returned from the call
>>>>>> because of some runtime decision made inside either an extension (where
>>>>>> the extension might not add fields for some reason) or a bit of core
>>>>>> code (by deciding not to call an extension at all)?
>>>>>> 
>>>>>> Doug
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> 
>>> 
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev