Hi, Apologies for the slow reply, long weekend because of a public holiday over here. I'm probably going to end up repeating part of what Alex has mentioned as well.
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 and extension/plugin. 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. 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. On Sun, Mar 8, 2015 at 11:01 AM, Jay Pipes <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 > > 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 > > 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 > > 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
