On 06/10, Dmitriy Rabotyagov wrote:
Oh, yes, this is a good alternative. Actually I was thinking about smth like "openstack <resource> event list" (as only nova does have that) for quite a while, but without having the resources to lead and help out in implementation across projects I didn't dare to raise this topic. But it's probably high time to start discussing it at the very least and make a proposal as a community goal based on the outcome of these discussions.
Hi, The Cinder team has also been exploring the idea of having transaction records to help operators see the series of operations on resources (to figure out what happened to a resource) as well as help see what operations are currently happening (great for planning upgrades or bouncing services to other nodes) [1]. If this is going to be a completely new feature in all projects we may want to agree on some commonalities such as naming and available functionality: - Transaction history, including deleted resources - Ongoing operations: - Detailed: All info for each of the transactions - Summary: - Global: i.e. 10 migrations, 3 attachments - By host: i.e. Host1: 5 migrations | Host2: 5 migrations, 3 attachments [1]: https://review.opendev.org/c/openstack/cinder-specs/+/845176/2/specs/zed/tra...
чт, 6 окт. 2022 г., 07:48 Artem Goncharov <artem.goncharov@gmail.com>:
Hey,
If this is there mostly for audit purposes then I guess a more efficient solution is to introduce an audit table which will have no performance impact on the "current state" of service. Audit records are also never updated means performance here is relatively straight forward. Audit may become a "feature" with enable switch.
This should be a better solution rather then letting db permanently grow and forcing admins to constantly "fight" against it. This also gives a much cleaner audit experience. Actually this is also not a new approach and is being followed in many places (i.e. auditd)
Regards, Artem
With this said, it's going to be difficult to get away from soft-delete quickly. Not only are there database migrations involved, but operators will need to rework their tooling to adapt to a new, no-soft-delete world. As such, I'd like to propose a half-way measure of making soft-delete configurable. To do this, I'd like to add a new flag in oslo.db, '[database] enable_soft_delete'. When set to 'False' anyone using the 'SoftDeleteMixin' from oslo.db would see these models hard deleted rather than soft deleted when calling 'soft_delete'. This would
I don't think it's a big deal, but from the Cinder perspective this would require additional work, because in our DB layer we only use the `soft_delete` method for 3 tables: Volume Types, Volume Type Access, and Group Type Access. All other tables use other mechanisms to do the soft deletes. Cheers, Gorka.
avoid the need for operators to run the various project-specific purge tooling. The RFC patch for this is available for review [1]. I can also do this on a project-specific basis and have proposed a similar patch for nova [2], however, doing it in oslo.db means every project that uses 'SoftDeleteMixin' in their models will get this for free. Projects that don't (glance, cinder) can switch to using this mixin and also get it for free.
As noted above, I intend to discuss this in the nova room at the PTG, but I'd be interested in people's thoughts ahead of time. Do you think this is a good idea? Should we proceed with it? Perhaps there are there better ways to do this? Let me know!
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/oslo.db/+/860407 [2] https://review.opendev.org/c/openstack/nova/+/860401