Bug #5255
closed
Calling version destroy takes 20+ minutes
Description
It looks like it's deleting repo packages during the plan phase. Also the deletion is really slow because it's using old code instead of the new code (which does batch updates).
Updated by David Davis almost 11 years ago
Total time was 23 minutes. I'm going to remove the hook in the ElasticSearch repo module and remove the orphan code from clear_packages_index.
Updated by David Davis almost 11 years ago
I created a separate dynflow action for updating the content in ElasticSearch when a repo gets deleted. Apparently the code was relying on the before_destroy hook.
Updated by David Davis almost 11 years ago
To test this:
Create a content view with RHEL 6 RPMs. Publish it. Remove the version via the CLI. Notice that the CLI times out. It should only take a matter of seconds to create a dynflow task. However, it's actually deleting the ES content in the plan phase.
Updated by David Davis almost 11 years ago
- Blocks Support #5179: Get a baseline for content view performance added
Updated by David Davis almost 11 years ago
- Subject changed from Calling version destroy takes 10+ minutes to Calling version destroy takes 25+ minutes
Updated by David Davis almost 11 years ago
- Subject changed from Calling version destroy takes 25+ minutes to Calling version destroy takes 20+ minutes
Updated by David Davis almost 11 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset katello|commit:1cf128184cf205e6d534ad213f9f8c5584b60bda.
Updated by Eric Helms over 10 years ago
- Translation missing: en.field_release set to 13