Bug 2040818

Summary: "foreman-maintain content migration-reset" spend a long time to cleanup everything
Product: Red Hat Satellite Reporter: Waldirio M Pinheiro <wpinheir>
Component: Foreman MaintainAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED WONTFIX QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: high Docs Contact:
Priority: high    
Version: 6.9.8CC: apatel, ggainey, iballou, kgaikwad
Target Milestone: UnspecifiedKeywords: Triaged, Upgrades
Target Release: Unused   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-14 14:03:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.