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

Jonathan LaCour jonathan-lists at cleverdevil.org
Thu Dec 12 21:42:05 UTC 2013

On December 11, 2013 at 2:34:07 PM, Doug Hellmann (doug.hellmann at dreamhost.com) wrote:

> On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello wrote:
> > 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?

After taking a close look at how the API is constructed, I
actually think that the current approach of having the API be
defined purely through extensions is flawed, for a few reasons:

1. The code is extremely difficult to read and follow, because the API
   structure is entirely built at runtime based upon what is
   installed, rather than expressed declaratively in code.

2. As a company providing a public cloud based upon OpenStack, with a
   desire to express compatibility with the "OpenStack API," its
   difficult to document the "standard" baseline Nova API. I shouldn't
   have to say "it depends" in API documentation.

3. Based upon my read, extensions are in no way "quarantined" from the
   the baseline/standard/required API. In fact, they seem to be able
   to pollute the standard API with additional parameters and
   functionality. I can not envision a world in which this is sane.

In my opinion, a well-designed and architected API should have the
core functionality declaratively defined in the code itself, so as to
give a good, well-documented, standard, and unchanging baseline. Then,
an "extension" capability should be layered on in such a way that it
doesn't alter the core API or serialized data.

Note: my opinion isn’t altered by the fact that some of the “core” 
API involves “required” extensions. The result is still difficult to
read and document.

That said, I don’t want to diminish or minimize the hard work that
has been done on the V3 API thus far! Lots of thinking and heavy
lifting has already been done, and its much appreciated. I am just
concerned that we lost our way somewhere. Major API revisions only
come along so often, and I’d prefer to raise my objections now 
rather than to hold them in and regret it!

Jonathan LaCour

More information about the OpenStack-dev mailing list