Open Stack

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/transaction-tracking.rst


> чт, 6 окт. 2022 г., 07:48 Artem Goncharov <artem.goncharov at 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
> >>>
> >>>
> >>>