[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