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