Bug 2122344
| Summary: | Run pulpcore-manager trim-rpm-changelogs during upgrades to 6.12 | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Daniel Alley <dalley> |
| Component: | Satellite Maintain | Assignee: | Evgeni Golov <egolov> |
| Status: | CLOSED ERRATA | QA Contact: | Griffin Sullivan <gsulliva> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.12.0 | CC: | ahumbe, aupadhye, bangelic, dhjoshi, egolov, ehelms, hakon.gislason, jpathan, Ken.Fowler, osousa, pdwyer, sadas, saydas, vferschm |
| Target Milestone: | 6.12.2 | Keywords: | Reopened, Triaged, Upgrades |
| Target Release: | Unused | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | rubygem-foreman_maintain-1.1.9 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-02-08 14:35:01 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
Daniel Alley
2022-08-29 20:12:16 UTC
It can be done at any time, even on 6.11, but for clarity's sake it would be best to recommend it during the 6.12 upgrade. Performing it during an upgrade downtime event would also prevent interference with ongoing publish operations (as there shouldn't be any). It is not strictly required to run and it is safe to run more than once by accident, so no concerns there. But it should significantly reduce the ongoing disk space requirements as well as improve overall performance. (In reply to Daniel Alley from comment #0) > We added a script which would clean up this unnecessary data, but nothing > triggers it to be executed. It's something that only ever needs to be run > once, so having "foreman-maintain upgrade" run it would result in waste. We can make foreman-maintain only call it "once" (well, twice): during/after 6.10→6.11 and during/after 6.11→6.12, which should ensure that all users got it executed at least once and then forget about it again. This is IMHO much better then documenting an addition step which users will for sure forget, we will have to write KCS for etc etc. If that's possible it may be a good idea, I was under the impression that it would have to run every time, including during minor version upgrades. Nah, we have separate execution plans for each X.Y→X.(Y+1) and for each "to latest X.Y.z" so we have full control when things are executed. For what it's worth, as of 6.12 (and 6.11 too if 6.11.4 were to pick up the patch) the changelogs of existing packages can also be slowly cleaned up over time as repositories are re-synced. So even if there were no manual or automatic installer steps, the situation will improve itself. That's an option too. If it doesn't get picked up for the last 6.11 release then we might want to have the KCS anyway. @egolov >re: "Nah, we have separate execution plans for each X.Y→X.(Y+1) and for each "to latest X.Y.z" so we have full control when things are executed." Just double checking, if a user upgraded directly to 6.12.3 or something, that wouldn't skip the step, would it? Or is that not a thing that can happen. Also is it not too late for an installer change for 6.12? (In reply to Daniel Alley from comment #9) > @egolov >re: "Nah, we have separate execution plans for each > X.Y→X.(Y+1) and for each "to latest X.Y.z" so we have full control when > things are executed." > > Just double checking, if a user upgraded directly to 6.12.3 or something, > that wouldn't skip the step, would it? Or is that not a thing that can > happen. If the user is coming from a 6.11.whatever, this step would be executed, yes. > Also is it not too late for an installer change for 6.12? For GA? Probably. Here's a patch that should do what you wanted: https://github.com/evgeni/foreman_maintain/commit/pulpcore-trim @Evgeni So the question now is whether it's worth putting in the installer at this point if it can't go into 6.12.0 Rather than tweaking that at this point, perhaps it is enough to just let it be resolved over time as they sync their repositories on 6.12, and then decide whether or not it is worth having the 6.13 perform the same fix for whatever hasn't already been cleaned up. not everyone upgrades on day 1, so having this as part of the "to 6.12" path for people who go once 6.12.1 is out sounds like a good thing to me, but I'll leave the decision to @ehelms (also, it's foreman maintain, not installer, but that's an implementation detail) We are moving this to foreman-maintain component to automate it as part of the 6.12 upgrade process, we will consider potentially including as part of the z-stream upgrade process. @dalley -- do you know what the rough runtime is for this command? Do you mean "added to the z-stream upgrade process" or "added to the 6.12 upgrade process in a z-stream"? If it was part of a z-stream upgrade then would it only run once or would it be triggered on every z-stream upgrade? The rough runtime depends entirely on the # of RPMs in the installation, and possibly how fast their database access is. I think we'd probably want to test it out on a dogfood box to get an approximation since my tests on a development system aren't very comparable. Created redmine issue https://projects.theforeman.org/issues/35678 from this bug Is there any indicator that can be used to determine *if* trim changelogs needs to run or has been previously run? Not really, no. And to be clear, if it's not run or if it's run multiple times, there won't be correctness issues or anything like that. This is merely cleaning up a bunch of superfluous data which is indirectly causing memory issues, using up disk space and slowing things down, which was contributing to a few other BZs. But as mentioned in comment #8 6.12 and forward can progressively clean that up over time (it didn't make it into 6.11.4 though), so I don't know how much energy it's worth spending to make sure we do a big cleanup up-front during the upgrade. It would be nice to know everything is consistent and cleaned up at a particular point, but not strictly *necessary*. We have opted to codify this as part of the upgrade process -- given it can save system resources for users it seems best to just do it for them during upgrade rather than rely upon them to see documentation. It is being included as part of the 6.12 and 6.12.z upgrade paths. Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/35678 has been resolved. Verified on Satellite 6.12.2 snap 1 pulpcore-manager rpm-trim-changelogs gets run during 6.11 to 6.12 upgrade. Steps to reproduce: 1) Get a 6.11 satellite with some content 2) Run upgrade to 6.12 3) Check logs for rpm-trim-changelogs messages Results: INFO -- : --- Execution step 'Trim RPM changelogs in the pulpcore db' [pulpcore-trim-rpm-changelogs] started --- DEBUG -- : Running command sudo PULP_SETTINGS=/etc/pulp/settings.py DJANGO_SETTINGS_MODULE=pulpcore.app.settings pulpcore-manager rpm-trim-changelogs with stdin nil You also get some output about trimming changelogs in the upgrade output Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Satellite 6.12.2 Async Update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:0668 |