Open Stack

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.