That covers routes. What about the properties of the inputs and outputs?
On Fri, Dec 13, 2013 at 4:43 PM, Ryan Petrello <[email protected]>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 > [email protected] > > On Dec 13, 2013, at 12:56 PM, Doug Hellmann <[email protected]> > wrote: > > > > > > > > > On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh <[email protected]> > wrote: > > On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes <[email protected]> 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 > > <[email protected] > > <mailto:[email protected]>>wrote: > > > > > > > > > > On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello < > > [email protected] > > <mailto:[email protected]>> > > 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 > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
