Heat/event-persistence
Motivation: Currently when we delete a stack, we remove all information associated with it from the database. This is a very bad idea (and not what AWS do) because it means that there is no record of the stack having ever existed. In particular, it is bad with the new rollback feature, since if a stack fails it will be rolled back by default and all records of *how* it failed destroyed.
Expectation: When a stack is deleted, we should mark it as deleted in the database (with a timestamp). Deleted stacks should not show up in the stack list or be accessible by name. New stacks whose names conflict with deleted stacks should be allowed. However, access to the deleted stack and its events using the ARN or UUID or (canonical) URL should be maintained.
Plan: Not breaking the existing foreign key not null constraints, the minimal set of tables that has to use soft delete is user_creds and raw_template apart from the stack and event tables.
If we want to completely migrate to soft delete for all tables, like other openstack components, we can first apply soft delete to only stack, event, user_creds and raw_template to avoid a big change at once. And after it gets merged into the code base, we can start working on the rest tables, resource, resource_data, watch_data, and watch_rule.
Major implementation steps: 1. Add two some volumes to the stack, event, user_cred, and raw_template tables.
deleted_at datetime YES NULL deleted int(11) YES NULL
2. DB migrate script Downgrade needs special treatment, as dropping the extra two columns is not enough. Those records that have been marked as soft deleted should be removed first.
3. DB access layer modifications Need to take into account a deleted option while accessing stacks, event, user_creds and raw_template. Deletion to stack, event, user_cred, and raw_template tables need to be done by marking the deleting records as deleted instead of physically removing them.
4. Nested stacks Treat nested stacks the same way as to resources - delete the database record;
5. heat-manage purge_events To delete soft deleted database records.
