Open Stack

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 <jaypipes at gmail.com
> <mailto:jaypipes at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>