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

Doug Hellmann doug.hellmann at dreamhost.com
Sat Dec 14 15:45:35 UTC 2013


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131214/235cb614/attachment.html>


More information about the OpenStack-dev mailing list