7f82c5e681
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
15 lines
771 B
YAML
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.
|