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
