[openstack-dev] [heat]Heat Db Model updates

Manickam, Kanagaraj kanagaraj.manickam at hp.com
Tue Jul 22 05:23:17 UTC 2014


Based on the comments, received, I have filed following defects. 

https://bugs.launchpad.net/heat/+bug/1346750
https://bugs.launchpad.net/heat/+bug/1346748
https://bugs.launchpad.net/heat/+bug/1346742
https://bugs.launchpad.net/heat/+bug/1346752


Hi Clint,
Persisting the events to the swift could be an blueprint. Could you please provide your suggestion. Thanks. 

Regards
Kanagaraj M
-----Original Message-----
From: Clint Byrum [mailto:clint at fewbar.com] 
Sent: Friday, July 18, 2014 3:54 AM
To: openstack-dev
Subject: Re: [openstack-dev] [heat]Heat Db Model updates

Excerpts from Manickam, Kanagaraj's message of 2014-07-16 20:48:04 -0700:
> Event
> Why uuid and id both used?

The event uuid is the user-facing ID. However, we need to return events to the user in insertion order. So we use an auto-increment primary key, and order by that in 'heat event-list stack_name'.

We don't want to expose that integer to the user though, because knowing the rate at which these integers increase would reveal a lot about the goings on inside Heat.

> Resource_action is being used in both event and resource table, so it 
> should be moved to common table

If we're joining to resource already o-k, but it is worth noting that there is a desire to not use a SQL table for event storage. Maintaining those events on a large, busy stack will be expensive. The simpler solution is to just write batches of event files into swift.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list