[openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?
jaypipes at gmail.com
Mon Mar 9 19:43:35 UTC 2015
On 03/09/2015 07:32 AM, Christopher Yeoh wrote:
> 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
> 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.
> 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*
> Sergey Nikitin is currently in the process of code review for the
> final patch that adds server instance tagging to the Nova API:
> 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:
> 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
> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev