On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann <doug.hellm...@dreamhost.com>wrote:
> > > > On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello < > 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. Chris > Doug > > > >> >> 2. The approach in my review would allow us to translate extensions to >> pecan piecemeal. To me, this seems like a more desirable and manageable >> approach than moving everything to pecan at once, given the scale of Nova’s >> API. Do others agree/disagree? Until all v3 extensions are translated, >> this means the v3 API is composed of two separate WSGI apps. >> >> 3. Can somebody explain the purpose of the wsgi.deserializer decorator? >> It’s something I’ve not accounted for yet in my pecan implementation. Is >> the goal to deserialize the request *body* from e.g., XML into a usable >> data structure? Is there an equivalent for JSON handling? How does this >> relate to the schema validation that’s being done in v3? >> >> --- >> Ryan Petrello >> Senior Developer, DreamHost >> ryan.petre...@dreamhost.com >> _______________________________________________ >> 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
