Open Stack

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 <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
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150309/bc77728a/attachment-0001.html>