On 16/07/14 23:48, Manickam, Kanagaraj wrote:
I have gone thru the Heat Database and found the drawbacks in the
existing model as listed below. Could you review and add anything
missing here. Thanks.
Heat Database model is having following drawbacks:
1.Duplicate information
2.Incomplete naming of columns
3.Inconsistency in the identifiers (id) and deleted_at columns across
the tables
4.resource table is specific to nova and make it generic
5.Pre-defined constants are not using enum.
And the section provided below describes these problem on table vice.
*Stack*
Duplicate info
Tenant & stack_user_project_id
These are different things; "stack_user_project_id" is the
project/tenant in which Heat creates users (in a different domain);
"tenant" is the project/tenant in which the stack itself was created.
Credentials_id & username , owner_id.
Tenant is also part of user_creds and Stack always has credentials_id,
so what is the need of having tenant info in stack table and in stack
table only the credentials_id is sufficient.
tenant is in the Stack table because we routinely query by tenant and we
don't want to have to do a join.
There may be a legitimate reason for the UserCreds table to exist
separately from the Stack table but I don't know what it is, so merging
the two is an option.
Status & action should be enum of predefined status
+1. I assume it is still easy to add more actions later?
*User_creads*
correct the spelling in Truststore_id
"trustor_user_id" is correct.
*Resource*
Status & action should be enum of predefined status
+1
Rsrc_metadata - make full name resource_metadata
-0. I don't see any benefit here.
Why only nova_instance column how about for other services like cinder,
glance resource, could be renamed to be generic enough??
+1 this should have been called "physical_resource_id".
*Watch_rule*
Last_evaluated -> append _at
I really don't see the point.
State should be an enum
+1
*Event*
Why uuid and id both used?
I believe it's because you should always use an integer as the primary
key. I'm not sure if it makes a difference even though we _never_ do a
lookup by the (integer) id.
Resource_action is being used in both event and resource table, so it
should be moved to common table
I'm not sure what this means. Do you mean a common base class?
Resource_status should be any enum
+1
cheers,
Zane.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
