Open Stack

On 03/09/2015 03:37 PM, Jay Pipes wrote:
> 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.
> 
> 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.

So possibly another way to think about this is our prior signaling of
what was supported by Nova was signaled by the extension list. Our code
was refactored into a way that supported optional loading by that unit.

As we're making things less optional it probably makes sense to evolve
the API code tree to look more like our REST resource tree. Yes, that
means servers.py ends up being big, but it is less confusing that all
servers related code is in that file vs all over a bunch of other files.

So I'd agree that in this case server tags probably should just be in
servers.py. I also think long term we should do some "plugin collapse"
for stuff that's all really just features on one resource tree so that
the local filesystem code structure looks a bit more like the REST url tree.

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150309/c8b6d988/attachment.pgp>