[openstack-dev] [Nova] Handling soft delete for instance rows in a new cells database

Jay Pipes jaypipes at gmail.com
Fri Nov 28 13:49:45 UTC 2014

On 11/27/2014 04:20 PM, Michael Still wrote:
> On Fri, Nov 28, 2014 at 2:59 AM, Jay Pipes <jaypipes at gmail.com> wrote:
>> On 11/26/2014 04:24 PM, Mike Bayer wrote:
>>>> Precisely. Why is the RDBMS the thing that is used for
>>>> archival/audit logging? Why not a NoSQL store or a centralized log
>>>> facility? All that would be needed would be for us to standardize
>>>> on the format of the archival record, standardize on the things to
>>>> provide with the archival record (for instance system metadata,
>>>> etc), and then write a simple module that would write an archival
>>>> record to some backend data store.
>>>> Then we could rid ourselves of the awfulness of the shadow tables
>>>> and all of the read_deleted=yes crap.
>>> +1000 - if we’re really looking to “do this right”, as the original
>>> message suggested, this would be “right”.  If you don’t need these
>>> rows in the app (and it would be very nice if you didn’t), dump it
>>> out to an archive file / non-relational datastore.   As mentioned
>>> elsewhere, this is entirely acceptable for organizations that are
>>> “obliged” to store records for auditing purposes.   Nova even already
>>> has a dictionary format for everything set up with nova objects, so
>>> dumping these dictionaries out as JSON would be the way to go.
>> OK, spec added:
>> https://review.openstack.org/137669
> At this point I don't think we should block the cells reworking effort
> on this spec. I'm happy for people to pursue this, but I think its
> unlikely to be work that is completed in kilo. We can transition the
> new cells databases at the same time we fix the main database.

No disagreement at all. The proposed spec is a monster one, and we can 
certainly make a lot of progress in Kilo, but I wouldn't expect it to be 
completed any time soon.


More information about the OpenStack-dev mailing list