Open Stack

On Fri, Dec 13, 2013 at 8:12 AM, Jonathan LaCour <
jonathan-lists at cleverdevil.org> wrote:

>
> 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.
>
>
So I'm too close to the code to have an unbiased opinion, but I found that
learning the V2 API code where parts of the API (core) were defined one way
and then extensions defined another even more confusing. Since they are
attempting
to achieve the same thing.

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.
>
>
The standard baseline for the Nova V3 API will be fixed. I think its a
decision higher up to
be made as to what is considered "OpenStack" but I'd be surprised if
OpenStack
compliant clouds were not permitted to add extra functionality to remain
compliant.


> 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.
>

Extensions can definitely add additional parameters and functionality and
that has been a pretty fundamental requirement for Nova development.
Perhaps this
will change as Nova matures, but at the moment we'd either have to stop new
features being added like being able to specify to a preserve_ephemeral
flag in rebuild
(just as one example happening in Icehouse), or have a major API version
every release.

Note that extensions are restricted to making only backwards compatible
changes
- eg behaviour has to stay the same if extra input parameters are not
present in a
request, and they can only add extra output parameters, they can't change
the value of
existing ones.


>
> 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!
>
>
So the idea of the V3 API originally came out of primarily wanting to clean
up many of the
warts, inconsistencies and bits of brokenness in the V2 API that we
couldn't because
of a requirement to keep backwards compatibility.  Perhaps in the future
Nova maturity
will reach the point where can start making guarantees like the core API is
never in anyway affected by extensions but I don't think we're there yet.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131213/e3f39141/attachment.html>