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:cl...@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@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
