Updated openstack/openstack
Project: openstack/heat  3f1f69bbd812ff7927da7b9542116c696723576f
null
Remove param explode_nested from doc

Remove param explode_nested from method resource_to_template document
since it does not exist in parameters.

Change-Id: I0ef14319bf6e39bb59a3d1753fc57bdb7698fe38
Updated openstack/openstack
Project: openstack/horizon  fd2523ac5e10ba8002c794f5e3c73d2c80b1cc1f
null
Update troveclient to 1.0.0

Closes-Bug: #1238121

Author: Robert Myers <robert.myers@rackspace.com>

Change-Id: I03d3d95602f4009c97d37fdf8e241ec8ab82389d
Updated openstack/openstack
Project: openstack/ceilometer  ff20b3986ffbe8b7d9bdce513e06bccb05a557b1
null
Add a specialized Event Type model and db table

As the events API gets fleshed out and more robust,
it will become increasingly necessary to ensure that the
database schema modeling events has the ability to quickly
retrieve a list of event types. With the current schema
having a foreign key from event to unique_name (the
monolithic generic string key lookup table), in order to
get a simple list of event types, one needs to do the following:

SELECT DISTINCT e.unique_name FROM event;

Not only is this inefficient, but the readability of the
model and database schema suffers from the generalization of
the unique name field relationship. With this patch, a new
event_type table is added to the schema to allow for quick
and easy lookups of event types like so:

SELECT id, desc FROM event_type;

This will lead to future ability to categorize
event types with ease. Instead of adding columns to the
monolithic unique_name table, we would only need to add a foreign
key relationship to the new event_type table tying the event_type
to a future event_type_class table...

This patch also renames "event_name" to "event_type" everywhere
to avoid confusion.

Change-Id: I6e630ec534f16ba1bb9370d1859ae7640fc6b05b
Partial-Bug: 1211015