On 03/09/2015 07:32 AM, Christopher Yeoh wrote:
<snip>
So the first thing I think we want to distinguish between plugins
being a REST API user or operator concept and it being a tool
developers use as a framework to support the Nova REST API. As I've
mentioned before I've no problem with the feature set of the API
being fixed (per microversion) across all Nova deployments. Get back
to me when we have consensus on that and its trivial to implement and
we'll no longer have the concept of core andextension/plugin.

Why are we continuing to add API extensions for new stuff?

But plugin like implementations using Stevedore as a tool for developers
to keep good modularity has proven to be very useful to keep complexity
level lower and interactions between modules much clearer.

Uhm, I beg to differ. The "plugin" implementation using Stevedore has made things way more complicated than they need to be.

It would be much simpler to have a single directory call /nova/api/openstack/compute/ with modules representing each resource collection controller.

> servers.py is
an example of this where in v2 I think we have/had the most complex
method and even with all the fix up work which has been done on it it is
still very complicated to understand.

It doesn't *need* to be more complicated. The microversions framework decorators allow us to encapsulate the differences between microversions for a particular method.

Best,
-jay

On Sun, Mar 8, 2015 at 11:01 AM, Jay Pipes <jaypi...@gmail.com
<mailto:jaypi...@gmail.com>> wrote:

    Hi Stackers,

    Now that microversions have been introduced to the Nova API (meaning
    we can now have novaclient request, say, version 2.3 of the Nova API
    using the special X-OpenStack-Nova-API-Version HTTP header), is
    there any good reason to require API extensions at all for *new*
    functionality.

    Sergey Nikitin is currently in the process of code review for the
    final patch that adds server instance tagging to the Nova API:

    https://review.openstack.org/#__/c/128940
    <https://review.openstack.org/#/c/128940>

    Unfortunately, for some reason I really don't understand, Sergey is
    being required to create an API extension called "os-server-tags" in
    order to add the server tag functionality to the API. The patch
    implements the 2.4 Nova API microversion, though, as you can see
    from this part of the patch:

    
https://review.openstack.org/#__/c/128940/43/nova/api/__openstack/compute/plugins/v3/__server_tags.py
    
<https://review.openstack.org/#/c/128940/43/nova/api/openstack/compute/plugins/v3/server_tags.py>

    What is the point of creating a new "plugin"/API extension for this
    new functionality? Why can't we just modify the
    nova/api/openstack/compute/__server.py Controller.show() method and
    decorate it with a 2.4 microversion that adds a "tags" attribute to
    the returned server dictionary?


Actually I think it does more than just add extra reponse information:
- it adds extra tags parameter to show
   - it doesn't add it to index, but it probably should add the response
information to detail to be consistent with the rest of the API
- It adds a new resource /servers/server_id/tags
    - with create, delete and delete all supported. I don't think that
these belong in servers.py

    
https://github.com/openstack/__nova/blob/master/nova/api/__openstack/compute/servers.py#__L369
    
<https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L369>

    Because we're using an API extension for this new server tags
    functionality, we are instead having the extension "extend" the
    server dictionary with an "os-server-tags:tags" key containing the
    list of string tags.

    This is ugly and pointless. We don't need to use API extensions any
    more for this stuff.


So we had a prefix rule originally in V2 to allow for extensions and
guarantee no name clashes. I'd be happy removing this requirement, even
removing old ones as long as we have consensus.

    A client knows that server tags are supported by the 2.4 API
    microversion. If the client requests the 2.4+ API, then we should
    just include the "tags" attribute in the server dictionary.

    Similarly, new microversion API functionality should live in a
    module, as a top-level (or subcollection) Controller in
    /nova/api/openstack/compute/, and should not be in the
    /nova/api/openstack/compute/__plugins/ directory. Why? Because it's
    not a plugin.

So I don't see how that changes whether we're using plugins (from a user
point of view) or not. The good news for you is that
there is fixing the shambles of a directory structure for the api is on
the list of things to do, it just wasn't a high prioirty things for us
in Kilo,
get v2.1 and microversions out. For example, we have v3 in the directory
path as well for historical reasons and we also have a contrib directory
in compute and none of those are really "contrib" now either.  Now the
nova/api/openstack/compute/ directory where you want to put all the v2
microversions code is currently full of v2 core code already.  It just
makes more sense to me to wait unti the old v2 core code can be removed
because the v2.1 api is considered equivalent and then move the v2.1
microversions code into its final place , rather than a shuffle now to
move the old v2 code (along with all the changes need to the unittests)
and then just have to delete it again not much longer.



    Why are we continuing to use these awkward, messy, and cumbersome
    API extensions?

    Please, I am begging the Nova core team. Let us stop this madness.
    No more API extensions.


It is still not clear to me exactly what you mean by use of an
extension. None of us ours are built for real runtime loading/unloading
of code (all loaded at the start or not at all). Use of hardcoding of
api controllers in V2 demonstrated its a good way of in the long run having
special exceptions for particular bits of api functionality because
people put in whatever they need at the time sometimes without a good
look at long term consequences and also they add implicit dependencies
which either aren't clear at all in the code.

Note that being able to load a subset or totally different set of
plugins is actually very useful for testing. For the first time we now
have tests which test the plugin framework itself which can use plugins
which are built purely to test the boundaries of what it can do, but
only live in the
test directories.

If your concern is just about openstack deployments being different from
each other because we support plugins then I don't think there is a
problem because we are all working towards to the state where it is a
fixed API and we're on that path. But if you want to get rid of
stevedore, then I strongly disagree because it has been a lot easier to
use and debug than V2 which was a mix of hardcoding the logic of loading
fixed modules (which is pretty gross) and some dynamic loading which was
not as good as stevedore anyway.


Regards,

Chris



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to