Open Stack

Hi guys,
Could you give some good ideas about add neutron common attributes into db table 'standardattributes'? Like timestamp, it must be a common one should be added.
The table 'standardattributes' is imported from [1]. It must be neutron common attrs should be added into this table in the future.


Now I had find a way to add timestamp based on subscribe/notify through defining a new subscribe resource named 'standardattr'. 
The code is [2][3]. I use this way as garyk is moving the extension resource from base code(db_base_plugin_base / db_base_plugin_v2 )to extension. I realize it will not be allowed to modify the code in base anymore. So I decide to add a mechanism into base code for not add the code when every new attribute addition, if we want to add other attributes into this table, we just fulfill their own field addition functions into db model. If my thought is reasonable, please add review list into [2][3].


Original, I just think I could set/get common attr through db_model.standardattr.(which column I had added into table and models/) , more details like network_model.standardattr.created_at/updated_at. I had made it in the patches [3] before. So I still have doubt about whether my way is correct or make it difficult. I wish your kind help and guidance. 


If there is some doubts of mine, please feel free to correct. I'm now still feel whether my way is right or can be accept by our community. If my way is too complex and useless, which way should I follow? Could anyone give your kind suggestions? Thanks.


And one more question:
I think make timestamp as extension is good, but there are some problem when use it.


1. As this bp will expand the tables in db of neutron core resources, whatever users use a plugin which support timestamp or not, db will still store the related data. 
-------My reason is: At first , if a plugin unable the timestamp and won't store data into db,  but when this plugin support this plugin once, db become to store timestamp.
-------This may cause issue about how to set the timestamp to the original data, if plugin enable/unable several times and create some resources during the change,
-------the db will contain some strange data, and when the plugin support timestamp at last, users will be confused why the resources created during the period of unable timestamp don't have the correct timestamp.
-------And it will cause some strong behaviors, like users create the base resource for a long time, why it doesn't have timestamp when it is true to open the timestamp.
2.Like the bp of mtu, I remember this field of network is as the neutron core attribute of network in the beginning. Now it had been moved to extension, and the field of mtu still be stored into db whatever plugin support mtu or not.
3.Like nova and other modules , the timestamp is treated as core attribute of resources, like instance, action list and so on. Neutron treat it as extension, so I think this timestamp of neutron should be drawn towards the usage of other modules. 
4.For other reasons, we can request the incremental query based on timestamp, when the scale is large, and there are so many messages or resources in system, no one want to list the info through get all of them.


So I have doubts about whether timestamp fields should be stored into db whatever the plugin support timestamp or not. When plugin support it, users could see them in the returned info. Wish your kind suggestion to help me to move on the timestamp. Thanks.


[1] https://review.openstack.org/#/c/222079/
[2] https://review.openstack.org/#/c/251193/ 
[3] https://review.openstack.org/#/c/213586/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151213/66c7da76/attachment.html>