Open Stack

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.hellmann at dreamhost.com
>> <mailto:doug.hellmann at dreamhost.com>>wrote:
>>
>>>
>>>
>>>
>>>> On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
>>>> ryan.petrello at dreamhost.com
>>>> <mailto:ryan.petrello at 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.

Best,
-jay