| Summary: | [RFE] make pulp regenerate applicability calculation incremental | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Pavel Moravec <pmoravec> |
| Component: | Pulp | Assignee: | satellite6-bugs <satellite6-bugs> |
| Status: | CLOSED WONTFIX | QA Contact: | Kersom <koliveir> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.1.6 | CC: | andrewrpalmer, andrew.schofield, bkearney, bmbouter, cduryee, chrobert, daviddavis, dkliban, egolov, ggainey, ipanova, ktordeur, mhrivnak, mvanderw, pcreech, peter.vreman, pmoravec, rchan, ttereshc, vanhoof |
| Target Milestone: | Unspecified | Keywords: | FutureFeature, Improvement |
| Target Release: | Unused | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-02-11 11:46:38 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: | |
| Bug Depends On: | |||
| Bug Blocks: | 1122832 | ||
|
Description
Pavel Moravec
2016-02-18 12:26:44 UTC
Dennis, could you please provide a workaround in cleaning the orphaned entries / profiles? I expect it to be: - list profile-hash that are in repo_profile_applicability but not in consumer_unit_profiles - delete from repo_profile_applicability any row having profile-hash from that list Please verify if I am right and prepare some script / mongo query to do so (I still feel I am mongo beginner). Pavel, I've investigated this issue and it looks like applicability is recalculated only for the existing profiles. You can see the code that ensures this behaviour here, there is also a long comment about that: https://github.com/pulp/pulp/blob/2.6-release/server/pulp/server/managers/consumer/applicability.py#L143-L151 (In reply to ttereshc from comment #3) > Pavel, > I've investigated this issue and it looks like applicability is recalculated > only for the existing profiles. You can see the code that ensures this > behaviour here, there is also a long comment about that: > https://github.com/pulp/pulp/blob/2.6-release/server/pulp/server/managers/ > consumer/applicability.py#L143-L151 Thanks for having a look. Adding some debug, I confirm the regenerate_applicability method is called only for profiles with a consumer. I will check with the customer behind what happens during the regenerate_applicability_for_repos method. Re https://github.com/pulp/pulp/blob/2.6-release/server/pulp/server/managers/consumer/applicability.py#L149-#L150 : is there a way how to trigger the monthly task manually? (pulp-admin does not sound to have a way to execute a task) I can manually hack the code in calling RepoProfileApplicability.objects.remove_orphans() somewhere, but that's not ideal, I guess. (In reply to Pavel Moravec from comment #4) > (In reply to ttereshc from comment #3) > > Pavel, > > I've investigated this issue and it looks like applicability is recalculated > > only for the existing profiles. You can see the code that ensures this > > behaviour here, there is also a long comment about that: > > https://github.com/pulp/pulp/blob/2.6-release/server/pulp/server/managers/ > > consumer/applicability.py#L143-L151 > > Thanks for having a look. Adding some debug, I confirm the > regenerate_applicability method is called only for profiles with a consumer. > I will check with the customer behind what happens during the > regenerate_applicability_for_repos method. > > Re > https://github.com/pulp/pulp/blob/2.6-release/server/pulp/server/managers/ > consumer/applicability.py#L149-#L150 : is there a way how to trigger the > monthly task manually? (pulp-admin does not sound to have a way to execute a > task) I can manually hack the code in calling > RepoProfileApplicability.objects.remove_orphans() somewhere, but that's not > ideal, I guess. There is no good way to remove these records, mostly because you do not need to. There is no harm to have them temporarily in db. It looks like this is working as expected, so I suggest closing as not a bug. An idea of substantial improvement: calculate the applicability incrementally Assume pulp has already synced a big repo with thousands of RPMs and hundreds of erratas. These have been already calculated in regenerate applicability. Now, syncing a new content from an importer brings say tens RPMs and few errata. Can't be the reg.app. task performed _only_ to the new units? Currently whole bunch of all units within the repo is recalculated completely from scratch. Incremental applicability calculations would be great, but Pulp would need versioned repositories for that to be possible. Pulp doesn't have versioned repositories that today. To get incremental applicability on upstream's radar, consider filing an issue in the upstream Pulp issue tracker for that feature request. It's at pulp.plan.io. Regarding Comment 6, the claim is that it is working as expected. Can this issue either be closed or have more info put on it that shows it's not working? I really value the input you've given so far, but I'm not sure how to proceed without more feedback from you. Despite I dont think regenerate applicability task taking hours for one repo is expected performance (like it was said to me), let deal with this BZ as an improvement to make the calculation incremental.
I request that for Satellite6 that suffers so many performance issues that qualify it as a valid request. I don't think I have to file the same in pulp upstream - that's rather engineering work, not support guy work (yes, I *can* do that, but that does not mean it's part of my job, still).
> but Pulp would need versioned repositories for that to be possible.
Why it can't use the info I see in Satellite task details "5 new packages downloaded" (I guess same info is available for any unit)? My (limited) understanding of repositories is that "repository versions" are individual *-updateinfo.xml.gz files that are downloaded - just the info from newly downloaded files can be used for the incremental reg.app. calculation (I guess same info can be found for other unit types).
Thanks for switching to be an improvement. Knowing which units have been added since the last sync time would be possible without versioned repos, but knowing which units have been deleted from a repo is not. Without that second part, we can't do incremental calculation and guarantee the profile is correct. Moving 6.2 bugs out to sat-backlog. Moving 6.2 bugs out to sat-backlog. Thanks Pavel and Brad. With that kind of timeline in mind I'm glad it's filed in upstream. The Pulp upstream bug status is at NEW. Updating the external tracker on this bug. The Pulp upstream bug priority is at Normal. Updating the external tracker on this bug. I have not seen slow applicability generation anymore in Sat6.2.x for a long time. Maybe this can be closed as duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1387314 (In reply to Peter Vreman from comment #23) > I have not seen slow applicability generation anymore in Sat6.2.x for a long > time. > Maybe this can be closed as duplicate of > https://bugzilla.redhat.com/show_bug.cgi?id=1387314 There is also https://bugzilla.redhat.com/show_bug.cgi?id=1573892 and similar https://bugzilla.redhat.com/show_bug.cgi?id=1523433 . (My feeling is that) time to time, a new performance bug of reg.app. task appears. Having reg.app. incremental would limit the harm of such bugs a lot. @tanya, what do you think about Peter and Pavels suggestion? Is the extra detail in the three bugs helpful, or should we look to consolidate them down? @Pavel, ok. I grepped also my logs of my Sandbox Sat6.3 system that has only 5 active hosts attached and i also see times up-to 3 minutes.
------
[crash/LI] root@li-lc-1578:~# grep 'regenerate_applicability_for_consume.*succeed' /var/log/messages | awk '{ print $11 }' | sort -n | tail -n20
155.618266692s:
155.686628891s:
155.76385391s:
155.815203646s:
155.839557005s:
155.949308844s:
156.007246163s:
156.026584353s:
156.085582285s:
156.150029303s:
156.382553215s:
156.396897227s:
156.401271272s:
156.404402644s:
156.648371257s:
164.205470193s:
167.079939475s:
167.47256931s:
167.997161549s:
168.064225609s:
-----------
Bryan, I'm looking at the BZ from comment#24 and they are valid complains, applicability is slow in a specific situation. And it's not a dup of any other BZ. This BZ is for incremental applicability calculation which is not possible (architecturally) to do in Pulp2. So we keep it to track it for Pulp 3 where we have repository versions and thus applicability calculation will be possible to do incrementally there. If you think we should treat it as Pulp 2 BZ only, then I can close it as WONTFIX. (In reply to Tanya Tereshchenko from comment #27) > If you think we should treat it as Pulp 2 BZ only, then I can close it as > WONTFIX. As an Improvement BZ, I am OK fixing it in pulp 3 only. This RFE might not be relevant anymore. Applicability feature design/planning is currently in progress. Expect to see the discussion on pulp-dev mailing list. The goal is to make it stateless in pulp 3, so the request to make it incremental wouldn't make sense. I'll update or close this BZ whenever the agreement on the feature design/implementation is reached. The RFE is not relevant anymore. Pulp 3 won't have applicability feature, it becomes purely Katello feature. The Pulp upstream bug status is at CLOSED - WONTFIX. Updating the external tracker on this bug. |