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/
__________________________________________________________________________
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
