Fix migration with fkeys

Creation of fkeys doesn't work in sqlite, so we should do these
changes in another dialects.
Fix bug 1204823.

Also we can have a problem with data conflicted with declared ForeignKey.
We should dump "bad" data to another place, upgrade and create FK.
Downgrade method should restore dumped data.

Change-Id: I33089d6f47dcde4cf716a3d303c8df23dd19cd07
Remove old sqlalchemy-migrate workaround

Change-Id: I29bf01da835077a663cd9ccb1a709db7adc4b121
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
Merge "Fix migration with fkeys"
Merge "Add a specialized Event Type model and db table"
Merge "Remove old sqlalchemy-migrate workaround"
Split collector

The collector grew from doing one thing to doing too many. This encumber
scalability and he's really a bad design as it is. Let's fix that.

This patch take out the notification handling code to a new daemon
called ceilometer-agent-notification. This daemon will be in charge of
receiving notifications, storing them if needed, and building samples in
from of it.

Change-Id: I093f3b7855bd6ffff2018db9cd485ed2fc0f37a5
Blueprint: split-collector
Merge ceilometer-collector and ceilometer-collector-udp

This will simplify deployment.

Change-Id: Iabf88eafae4e95825016d382cfa86ceb8c38f880
Move dispatcher a level up

Dispatcher as it is designed now is used by both collector and
agent-notification, so let's move it level upper. This makes a more flat
hierarchy.

Change-Id: I681bf58f0b26cca22a48e6655db2547e59f9e805
Remove the collector submodule

It's useless to have a submodule with just one service, simplify the
hierarchy.

Change-Id: I4c39ea74fc5cb59d487626b998eaed9c5cf30eff
Use map_method from stevedore 0.12

This simplifies the code a bit.

Change-Id: If8b95bf8cd8c240efde51aa8b268a26998042345
Simplify the dispatcher method prototype

`record_metering_data' is receiving a context that is never used in the
dispatch drivers. So let's remove it to simplify our code and
interfaces.

Change-Id: I811fe86b86749de4c4d52a57e761021604f7b818
Avoid intermittent integrity error on alarm creation

Fixes bug 1255107

Previously, alarm creation failed intermittently with the
sqlalchemy driver, due to the reliance on session merge to create
the project & user IDs if not already encountered.  This approach
conflicted with the strict foreign key constraints that were
added to the alarms table as an after-thought.

Now, we avoid the potential problem by explicitly creating the
project and user IDs if necessary.

Unfortunately, this cannot be tested via the scenario tests,
as there we use sqlite (the problematic migration does not
apply the foreign key constraints for that engine).

Change-Id: Ieaed676a0a68725242fadbf658646b874d6851ce
Change metadata_int's value field to type bigint

Change-Id: Icac8bd1cf55da9f645b5e27c45b6c2c918dcdab3
Closes-Bug: 1254604
Added resources definition in the pipeline

The 'resources' in the pipeline definition is a list of endpoints for
the pollsters to get the data from. It's optional and it's up to the
specific pollsters to decide how to use it.

The new pipeline definition could be something like the following:

    meters:
        - "*"
    resources:
        - file:///foo/bar/endpoints

Implements: blueprint support-resources-pipeline-item
Change-Id: Ibd7426f8f453c176c99d3786106deb35bbac8d4f
Fixed nova notifier test

Fixed nova notifier test due to the nova change
https://review.openstack.org/54493.

Change-Id: Ia3b81eb63f642668185474b2a5a15d3fc0d87b1c
Closes-Bug: 1255409
Fixed a bug in sql migration script 020

In sql migration script 020_add_metadata_tables.py, the sql statements
to insert metadata from the meter table to the newly created tables
have never been executed.

Change-Id: I211e024ed8be65a19f670ce72e3035c8f8797a54
Merge "Merge ceilometer-collector and ceilometer-collector-udp"
Merge "Move dispatcher a level up"
Merge "Remove the collector submodule"