Hi Zane, Please find inline answer.
Regards Kanagaraj M -----Original Message----- From: Zane Bitter [mailto:zbit...@redhat.com] Sent: Thursday, July 17, 2014 10:01 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [heat]Heat Db Model updates 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. KanagarajM > > 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. Kanagaraj M> user_creds are being consumed by stack only and I feel that for one user say 'admin1' there will be one row in user_Creds table and who can have more than one stacks owned. I assumed this could be the reason. But to validate, I created two stacks with same user and for each stack, a seprate row is created. So as you suggested, I also feel that stack and user_creds could be merged if there is no other fact. And it will remove the redundancy too. > 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. Kanagaraj M> sure. > *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. KanagarajM > It is to just make consistency in naming format > 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. KanagarajM > It is to just make consistency in naming format when we say created_at, updated_at and so last_evaluated_at. > 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. Kanagaraj M> In openstack, most of the services migrated from using INT to UUID for the primary key. And more than that, it would be nice to make consistency. The reason is, when the user access the resource over REST API, if we use UUID for the all the entities used in the heat project, it will make user/developer experience easier. > 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? KanagarajM > Yes, its an implementation specific and have a common python 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
