2015-03-10 3:37 GMT+08:00 Jay Pipes <jaypi...@gmail.com>: > On 03/08/2015 08:10 AM, Alex Xu wrote: > >> Thanks for Jay point this out! If we have agreement on this and document >> it, that will be great for guiding developer how to add new API. >> >> I know we didn't want extension for API. But I think we still >> need modularity. I don't think we should put everything in a single >> file, that file will become huge in the future and hard to maintenance. >> > > I don't think everything should be in a single file either. In fact, I've > never advocated for that. > > We can make the 'extension' not configurable. Replace 'extension' with >> another name, deprecate the extension info api int he future.... But >> that is not mean we should put everything in a file. >> > > I didn't say that in my email. I'm not sure where you got the impression I > want to put everything in one file? > > For modularity, we need define what should be in a separated module(it >> is extension now.) There are three cases: >> >> 1. Add new resource >> This is totally worth to put in a separated module. >> > > Agreed. > > 2. Add new sub-resource >> like server-tags, I prefer to put in a separated module, I don't >> think put another 100 lines code in the servers.py is good choice. >> > > Agreed, which is exactly what I said in my email: > > "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." > > 3. extend attributes and methods for a existed resource >> like add new attributes for servers, we can choice one of existed >> module to put it in. Just like this patch >> https://review.openstack.org/#/c/155853/ >> But for servers-tags, it's sub-resource, we can put it in its-own >> module. >> > > Agreed, and that's what I put in my email. > > If we didn't want to support extension right now, we can begin from not >> show servers-tags in extension info API first. That means extension info >> is freeze now. We deprecated the extension info api in later version. >> > > I don't understand what you're saying here. Could you elaborate? What I am > asking for is for new functionality (like the server-tags subcollection > resource), just add a new module called > /nova/api/openstack/compute/server_tags.py, > create a Controller object in that file with the new server tags resource, > and don't use any of the API extensions framework whatsoever. > > Ok, I think I see you now. Forgive me for any misunderstood.
Actually I mean we can freeze and depreciated the '/extensions' API at here. We can freeze the '/extensions' API now, didn't show server-tags extension in that API. Follow the discussion, I think there is two things related to 'extension'. One is '/extensions' API, another one is plugin framework. And I added devref about that https://review.openstack.org/162912 For the modularity, I put in separated patch https://review.openstack.org/162913 Those two things I think we can discussion them separately. (Emm.....This is kind of evidence about I misunderstood you) > In addition to that, for the changes to the main GET /servers/{server_id} > resource, use microversions to decorate the > /nova/api/openstack/compute/servers.py.Controller.show() > method for 2.4 and add a "tags" key to the dict (note: NOT a > "os-server-tags:tags" key) returned by GET /servers/{server_id}. No use of > API extensions needed. > > Best, > -jay > > Thanks >> Alex >> >> 2015-03-08 8:31 GMT+08:00 Jay Pipes <jaypi...@gmail.com >> <mailto:jaypi...@gmail.com>>: >> >> 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? >> >> 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. >> >> 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. >> >> 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. >> >> Best, >> -jay >> >> ____________________________________________________________ >> __________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > >> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev >> <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 >> >> > __________________________________________________________________________ > 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