nova/releasenotes/notes/aggregates-moved-to-api-database-e1bd30909aaf79d3.yaml
Mark Doffman 7f82c5e681 Aggregate create and destroy work against API db
Make aggregate.create() and destroy() use the API rather than cell database.
Also block aggregate creation until main database empty. This makes
Aggregate.create() fail until the main database has had all of its aggreagtes
migrated. Since we want to avoid any overlap or clashes in integer ids we
need to enforce this.

Note that this includes a change to a notification sample, which encodes
the function and module of a sample exception (which happens to be during
an aggregate operation). Since the notifications are encoding internal
function names, which can and will change over time, this is an expected
change.

blueprint cells-aggregate-api-db

Co-Authored-By: Dan Smith <dansmith@redhat.com>
Change-Id: Ida70e3c05f93d6044ddef4fcbc1af999ac1b1944
2016-08-01 08:22:08 -07:00

15 lines
771 B
YAML

---
upgrade:
- Aggregates are being moved to the API database for CellsV2. In this
release, the online data migrations will move any aggregates you have
in your main database to the API database, retaining all
attributes. Until this is complete, new attempts to create aggregates
will return an HTTP 409 to avoid creating aggregates in one place that
may conflict with aggregates you already have and are yet to be
migrated.
- Note that aggregates can no longer be soft-deleted as the API
database does not replicate the legacy soft-delete functionality
from the main database. As such, deleted aggregates are not migrated
and the behavior users will experience will be the same as if a
purge of deleted records was performed.