| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Instead of implementing a similar version to what the
upgrade function does, just use it directly instead.
Change-Id: I61a3c9f09c6e0724f2b55951989171ef4aaafe0c
|
| |
|
|
|
|
|
|
|
| |
Remove line containing
comment - # vim: tabstop=4 shiftwidth=4 softtabstop=4
Change-Id: I7581cc88b8de433d5609ed06c6570b0b45c13573
Closes-Bug:#1229324
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of having a pretty restrictive module
based api for saving logbook objects it is much
more friendly and extensible to move toward a more
ceilometer-influenced engine and connection based
storage backend using stevedore to do the backend
loading instead of a custom registration/fetching
mechanism. This allows us to provide a base object
oriented backend api that can be easily inherited
from to allow for customized & pluggable backend
storage modules.
Implements blueprint stevedore-based-backends
Implements blueprint ceilometer-influenced-backends
Change-Id: Ib5868d3d9018b7aa1a3354858dcb90ca1a04055d
|
|
|
1. Simplify the exposed api to reduce race conditions
which could occur if we allowed flow details, task
details and log books to be deleted at different
times; reduce this down to just being able to save and
delete from logbooks (and only save/update for flow
and task details to) to reduce the problem cases.
2. Introduce a alembic migration with a proper schema so that
the initial database can be created in the first place,
adjust its exposed fields and relations to be defined
by said schema.
3. Use oslo db models instead of our own.
Change-Id: I78bbedf87d506d3f39157198638937c933235b7b
|
