Bug 2233448
Summary: | CV with filters (or republishing any CV version) causes modules lose flags ([d]efault) | ||
---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Jan Jansky <jjansky> |
Component: | Pulp | Assignee: | satellite6-bugs <satellite6-bugs> |
Status: | CLOSED WONTFIX | QA Contact: | Satellite QE Team <sat-qe-bz-list> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.13.2 | CC: | dalley, iballou, pmoravec, rlavi |
Target Milestone: | Unspecified | Keywords: | Triaged |
Target Release: | Unused | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2024-05-15 01:54:46 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
Jan Jansky
2023-08-22 09:02:44 UTC
A different reproducer for the same root cause suggests two things: 1) even for a CV without filters, republish CV version does expensively generate pieces of metadata *like* the CV has filters - while originally CV publish just quickly copied metadata from Library repo (is this expensive metadata generation really required? can't we behave like during CV publish here?) 2) publishing CV with filters does also forget to add the default modularity enablednes! The reproducer itself: - create CV with RHEL9 BaseOS and AppStream repos - publish the CV and check modulemd-defaults in modules.yaml repodata (will be present) - add CV filter "exclude sos RPMs". Those packages from BaseOS should have zero impact to AppStream repo content, at all (no AppStream content depends in either way on sos, imho) - publish the CV and check modulemd-defaults in modules.yaml repodata (will be missing) - replace the filter by "exclude acpid RPMs" (acpid is some AppStream RPM that should not (afaik, worth to double-check) impact anything modularity-related - publish the CV again, and check the modulemd-defaults in modules.yaml repodata again (will be missing) How to check modulemd-defaults in modules.yaml repodata : either using a client system assigned to the CV, or directly in artifacts bits on Satellite, via: # cat modules-artifact.py from pulp_rpm.app.models.repository import RpmDistribution for distr in RpmDistribution.objects.all(): if not distr.publication or not distr.publication.published_metadata: continue modfilter = distr.publication.published_metadata.filter(relative_path__contains='modules.yaml') if modfilter.count() > 0: print(f"{modfilter.first().contentartifact_set.first().artifact.file.path} {distr.base_path}") # Then run: cat modules-artifact.py | sudo -u pulp PULP_SETTINGS='/etc/pulp/settings.py' DJANGO_SETTINGS_MODULE='pulpcore.app.settings' pulpcore-manager shell | grep "/9/x86_64/appstream/os" | while read ART DPATH; do echo "$ART $(zgrep -c modulemd-defaults $ART) $DPATH"; done to see: .. /var/lib/pulp/media/artifact/28/972408412b083f2840c0b4fdecd2b273c44620bb462061e6f53656c28310ae 5 JJAN_ORG/content_views/RHEL9/4.0/content/dist/rhel9/9/x86_64/appstream/os /var/lib/pulp/media/artifact/29/1042c6c4ef45ee07d9e2608bbd74d94a00861dd4a5438fcf2db160c1896ad8 0 JJAN_ORG/content_views/RHEL9/5.0/content/dist/rhel9/9/x86_64/appstream/os .. meaning "RHEL9 content view in version 4.0 has modules.yaml artifact file stored in ..0ae file, and it has five modulemd-defaults pieces (the right modularity enabledness defaults)", BUT "RHEL9 content view in version 5.0 has modules.yaml artifact file stored in ..ad8 file, and it has zero modulemd-defaults pieces (missing modularity enabledness defaults)" My gut feeling is that katello is guilty here (in Actions::Pulp3::Repository::CopyContent step? just guessing) - since CV filters (katello stuff) does affect the outcome; I *think* katello forgets to tell pulp "hey, please copy *also* modularity default enabledness info". I agree with Pavel's analysis. We probably need to copy all modulemd defaults in this method: https://github.com/Katello/katello/blob/master/app/services/katello/pulp3/repository/yum.rb#L381 For yum content in Sat 6.10, we used the "multi-copy" methods for all filtered content view copying. We switched over to only using the multi-copy methods when dependency solving to speed things up in Sat 6.11: https://github.com/Katello/katello/commit/3ac597399a06893457d6ceaa4ce339ad8aa44a4f. We do copy modulemd defaults in `multi_copy_units`, but nowhere else in the file. Created redmine issue https://projects.theforeman.org/issues/36749 from this bug I wasn't able to reproduce this on the latest code and took a closer look on Satellite 6.13 -- it seems that Pulp isn't syncing modulemd_defaults from the RHEL 9 AppStream repository for some reason. Not only does the content view repository not have modulemd_defaults, but the library repository is missing them as well. The filtering matters due to mirroring -- the mirror taken directly from the upstream has the modulemd_default information already in it. However, when telling Pulp to generate the modular metadata itself via either filtering or repository republishing, the modulemd_default information disappears. RHEL 9 AppStream Library on Jan's reproducer: ``` "present": { "rpm.advisory": { "count": 2904, "href": "/pulp/api/v3/content/rpm/advisories/?repository_version=/pulp/api/v3/repositories/rpm/rpm/85686487-5c99-4be3-b3a1-a7f956606a62/versions/39/" }, "rpm.modulemd": { "count": 14, "href": "/pulp/api/v3/content/rpm/modulemds/?repository_version=/pulp/api/v3/repositories/rpm/rpm/85686487-5c99-4be3-b3a1-a7f956606a62/versions/39/" }, "rpm.package": { "count": 11796, "href": "/pulp/api/v3/content/rpm/packages/?repository_version=/pulp/api/v3/repositories/rpm/rpm/85686487-5c99-4be3-b3a1-a7f956606a62/versions/39/" }, "rpm.packagecategory": { "count": 5, "href": "/pulp/api/v3/content/rpm/packagecategories/?repository_version=/pulp/api/v3/repositories/rpm/rpm/85686487-5c99-4be3-b3a1-a7f956606a62/versions/39/" }, "rpm.packageenvironment": { "count": 4, "href": "/pulp/api/v3/content/rpm/packageenvironments/?repository_version=/pulp/api/v3/repositories/rpm/rpm/85686487-5c99-4be3-b3a1-a7f956606a62/versions/39/" }, "rpm.packagegroup": { "count": 63, "href": "/pulp/api/v3/content/rpm/packagegroups/?repository_version=/pulp/api/v3/repositories/rpm/rpm/85686487-5c99-4be3-b3a1-a7f956606a62/versions/39/" }, "rpm.repo_metadata_file": { "count": 1, "href": "/pulp/api/v3/content/rpm/repo_metadata_files/?repository_version=/pulp/api/v3/repositories/rpm/rpm/85686487-5c99-4be3-b3a1-a7f956606a62/versions/39/" } } ``` On my 6.13 reproducer: ``` "present": { "rpm.advisory": { "count": 2935, "href": "/pulp/api/v3/content/rpm/advisories/?repository_version=/pulp/api/v3/repositories/rpm/rpm/114633d1-a9ce-4df2-94ce-25910d361cc7/versions/2/" }, "rpm.modulemd": { "count": 14, "href": "/pulp/api/v3/content/rpm/modulemds/?repository_version=/pulp/api/v3/repositories/rpm/rpm/114633d1-a9ce-4df2-94ce-25910d361cc7/versions/2/" }, "rpm.package": { "count": 12041, "href": "/pulp/api/v3/content/rpm/packages/?repository_version=/pulp/api/v3/repositories/rpm/rpm/114633d1-a9ce-4df2-94ce-25910d361cc7/versions/2/" }, "rpm.packagecategory": { "count": 5, "href": "/pulp/api/v3/content/rpm/packagecategories/?repository_version=/pulp/api/v3/repositories/rpm/rpm/114633d1-a9ce-4df2-94ce-25910d361cc7/versions/2/" }, "rpm.packageenvironment": { "count": 4, "href": "/pulp/api/v3/content/rpm/packageenvironments/?repository_version=/pulp/api/v3/repositories/rpm/rpm/114633d1-a9ce-4df2-94ce-25910d361cc7/versions/2/" }, "rpm.packagegroup": { "count": 63, "href": "/pulp/api/v3/content/rpm/packagegroups/?repository_version=/pulp/api/v3/repositories/rpm/rpm/114633d1-a9ce-4df2-94ce-25910d361cc7/versions/2/" }, "rpm.repo_metadata_file": { "count": 1, "href": "/pulp/api/v3/content/rpm/repo_metadata_files/?repository_version=/pulp/api/v3/repositories/rpm/rpm/114633d1-a9ce-4df2-94ce-25910d361cc7/versions/2/" } } ``` I'm changing this into a Pulp BZ since Katello isn't filtering out the modulemd_defaults. @dalley do you know why the modulemd_defaults might not be getting synced? >> I wasn't able to reproduce this on the latest code and took a closer look on Satellite 6.13 -- it seems that Pulp isn't syncing modulemd_defaults from the RHEL 9 AppStream repository for some reason. Not only does the content view repository not have modulemd_defaults, but the library repository is missing them as well.
RHEL 9 doesn't have any modulemd_defaults (and will never). They got rid of them after RHEL 8
The "defaults" are just nonmodular packages and if you want some alternate stream then there are modules for those.
Daniel, if the modulemd_defaults in the repodata are not needed in RHEL 9, how would you handle this BZ? It seems there is a noticeable difference with the default symbol going away in the DNF report, so users might continue to report it as a bug. We might need a KCS to explain why the defaults, useful or not, might go missing. Hold up, I'm gonna need to as some questions because there aren't supposed to be any module defaults in the RHEL 9 appstream repo so far as I know, but there are... Ok, it's just an overlap in meanings. There are "modulemd-defaults" metadata in modules.yaml, but they don't define any default modules, they just list the profiles. I'm not able to reproduce this on the latest versions of the code. If it's broken on older versions, I'd guess that probably libmodulemd is being picky about something in the metadata and silently ignoring them (again). As of 6.14 we don't use libmodulemd anymore so that might explain why it would be fine now. I don't have time to dig deeper at the moment Since the bug is present only in 6.13 (I can confirm 6.14 has it fixed) and it was hit just by one customer that upgraded to 6.14, and since it is low severity bug, I would suggest closing the Jira and BZ. Let me know if somebody insists on fixing this on 6.13.z . Relevant KCS is already created & linked. |