Bug 2040818 - "foreman-maintain content migration-reset" spend a long time to cleanup everything
Summary: "foreman-maintain content migration-reset" spend a long time to cleanup every...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Foreman Maintain
Version: 6.9.8
Hardware: All
OS: All
high
high
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Satellite QE Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-01-14 18:32 UTC by Waldirio M Pinheiro
Modified: 2023-07-14 14:03 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-07-14 14:03:41 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Waldirio M Pinheiro 2022-01-14 18:32:39 UTC
Description of problem:
Once the customer starts the pulp data migration, if necessary for any reason to reset the whole thing, I believe in the backend we are doing basically two things, cleaning the filesystem and also the database.

Working with a huge customer dataset, near 800GiB of data in the local filesystem, this process spent more than 6hours.

Version-Release number of selected component (if applicable):
6.9

How reproducible:
100%

Steps to Reproduce:
1. Enable and Sync the repos as immediate, something near ~800GiB in the filesystem
2. Start the data migration
3. After some days, try to reset

Actual results:
A lot of time to clean-up everything, at least 6 hours in the test env with ~800GiB

Expected results:
The cleanup/wipe process should be real quick, then the customer should be able to restart the process

Additional info:



[1]. https://access.redhat.com/documentation/en-us/red_hat_satellite/6.10/html-single/upgrading_and_updating_red_hat_satellite/index#preparing_to_migrate_pulp_content

Comment 1 Grant Gainey 2022-02-21 16:36:18 UTC
Reset takes a long time when there's a lot of data, because on the Pulp3 side, reset can be selective - e.g., you can reset "just pulp-rpm" or "just pulp-container". That means the service can't just truncate/drop/recreate database tables, it has to remove entities, and related content (which may not be foreign-key-related, so Pulp can't even rely on CASCADE deletes).

Comment 2 Waldirio M Pinheiro 2022-02-22 17:52:04 UTC
Hello Grant,

Thank you for the heads up. Could you think about anything that could speed up this clean-up process? If not, I believe we could at least, share during this process some deadline when starting the process.

Thank you again, my friend.
Waldirio

Comment 3 Grant Gainey 2022-02-23 20:09:05 UTC
(In reply to Waldirio M Pinheiro from comment #2)
> Hello Grant,
> 
> Thank you for the heads up. Could you think about anything that could speed
> up this clean-up process? If not, I believe we could at least, share during
> this process some deadline when starting the process.
> 
> Thank you again, my friend.
> Waldirio

Pulp allows for selective-cleanup. If what we want is a "Just Do It" reset, I could envision a foreman-maintain task that stops the Pulp3 services and resets Pulp3's database to empty-post-install state. It's not as easy as "just trunc all the tables", because there's DDL that happens at install (setting up constant tables, admin user, that sort of thing).

Comment 4 Ian Ballou 2023-07-14 14:03:41 UTC
Closing this BZ as WONTFIX. 6.9 is EOL and this is not an upgrade-blocking issue.  I agree with Grant's comment in Comment 3, and that makes this more of an RFE anyway.


Note You need to log in before you can comment on or make changes to this bug.