Description of problem: After upgrading to Satellite 6.10, the exclud filters are not behaving in the same way as they did for Satellite 6.9 (pulp2). When a CV has both rpm and kickstart type repos, and an exclude filter has been created by keeping it applicable to all repos, the newly published version of the view will miss certain yum package groups which are related to the excluded package and the group will basically be missing from all repos in that published version of CV. Version-Release number of selected component (if applicable): Satellite 6.10 How reproducible: Always Steps to Reproduce: 1. Create a Satellite 6.9 and another Satellite 6.10 2. Import manifest in both and enabled + sync these two repos in both of them. Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server Red Hat Enterprise Linux 7 Server Kickstart x86_64 7.9 3. Create a CV in both satellite called , RHEL7 where, * Above repos are added * Following exclude filter is created and set applicable for all repos. --------|-----------|--------------------------|-------------------- RULE ID | FILTER ID | NAME | MINIMUM VERSION --------|-----------|--------------------------|-------------------- 1 | 1 | java-11-openjdk | 11.0.13.0.8-1.el7_9 2 | 1 | java-11-openjdk-headless | 11.0.13.0.8-1.el7_9 --------|-----------|--------------------------|-------------------- 4. Publish a new version of the CV to Library environment and this should create version 1.0 of the CV itself with content-view-version-id 2 (assuming). 5. Inquiry the package group information from the published version of the CV using hammer commands or by directly checking the comps.xml file from the published path of repo. Actual results: On Satellite 6.9, the package group information is available even though the expected packages are successfully excluded. # hammer package-group list --content-view RHEL7 --lifecycle-environment-id 1 --per-page 9999 --search "name = Base" ---|--------------------|--------------------------------------------------------|------------------------------------- ID | PACKAGE GROUP NAME | REPOSITORY NAME | UUID ---|--------------------|--------------------------------------------------------|------------------------------------- 78 | Base | Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server | 01bc946b-5122-4b17-90ca-623f622ddb5f 55 | Base | Red Hat Enterprise Linux 7 Server Kickstart x86_64 7.9 | c20c3196-e3f1-4d14-9cb1-da972ba63976 ---|--------------------|--------------------------------------------------------|------------------------------------- Even if we investigate the comps.xml of kickstart 7.9 from the published version of view i.e. from /var/lib/pulp/published/yum/http/repos/*/Library/RHEL7/content/dist/rhel/server/7/7.9/x86_64/kickstart/repodata , It will show us the Base group available. On Satellite 6.10, The package group Base is completely missing: # hammer package-group list --content-view-version-id 2 --per-page 9999 --search "name = Base" ---|--------------------|-----------------|----- ID | PACKAGE GROUP NAME | REPOSITORY NAME | UUID ---|--------------------|-----------------|----- Also, from UI --> Content --> Content Views --> RHEL7 --> Click on Version 1.0 --> Click on "rpm Package Groups" --> Search by "name = Base" without quotes and nothing will appear And if we are using this CV + LCE to build a system, and the kickstart is calling "@Base" or "@dditional Development" groups , the build will fail with error that Anaconda was not able to find any such groups. Expected results: The package groups should not be missing from the CV even if a related package is being excluded. Additional info: On Sat 6.10, If we edit the CV filter and Go to "Affected Repositories" tab, Selecting the option "This filter applies only to a subset of repositories in the content view." and then ensure to either just select "Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server" or ensure to select all repos but not the Kickstart 7.9, then saving the same and publishing a new version of CV, will bring back the Base and Other missing groups inside in that version from Kickstart 7.9 repo. hammer> package-group list --content-view-version-id 2 --per-page 9999 --search "name = Base" ----|--------------------|-----------------------------------------------------------------|----------------------------------------------------------------------------- ID | PACKAGE GROUP NAME | REPOSITORY NAME | UUID ----|--------------------|-----------------------------------------------------------------|----------------------------------------------------------------------------- 115 | Base | Red Hat Enterprise Linux 7 Server Kickstart x86_64 7.9 | /pulp/api/v3/content/rpm/packagegroups/7cf90a3e-77e5-467a-ba11-0070ca5df2e5/ ----|--------------------|-----------------------------------------------------------------|----------------------------------------------------------------------------- So it is either the fact that Pulp2 was working wrong or It's the fact that Pulp 3 is behaving unexpectedly here and we need to ensure not to select all repos while using a filter but only select the ones from where we want to exclude the packages.
hi Sayan, I dug into this a bit more and the problem is slightly different than initially positioned. Satellite 6.10 does not include a package group unless all its packages are present (I think this is a change from 6.9, but i will have to confirm). Changing this behavior does cause the package group to show up, but I noticed that NONE of the java-11-openjdk packages were showing up in either repository. It turns out that these packages are using an epoch: java-11-openjdk-1:11.0.8.10-1.el7.x86_64 So changing this to 1:11.0.13.0.8-1.el7_9 caused everything to work properly, as '11.0.13.0.8-1.el7_9' was assuming a zero epoch, which meant that every java-11-openjdk package was excluded. So while there may be a bug here around package groups, for this particular customer, i'd recommend changing their filter to include the epcoh "1" at the front of the version string, and then i think everything will work for them. Justin
After chatting with the pulp team, we can switch the behavior back to match 6.9's behavior. I would still recommend this particular user to adjust their filter though!
Created redmine issue https://projects.theforeman.org/issues/34399 from this bug
Upstream bug assigned to jsherril
(In reply to Justin Sherrill from comment #1) > hi Sayan, > > I dug into this a bit more and the problem is slightly different than > initially positioned. > > Satellite 6.10 does not include a package group unless all its packages are > present (I think this is a change from 6.9, but i will have to confirm). > Changing this behavior does cause the package group to show up, but I > noticed that NONE of the java-11-openjdk packages were showing up in either > repository. It turns out that these packages are using an epoch: > > java-11-openjdk-1:11.0.8.10-1.el7.x86_64 > > So changing this to 1:11.0.13.0.8-1.el7_9 caused everything to work > properly, as '11.0.13.0.8-1.el7_9' was assuming a zero epoch, which meant > that every > java-11-openjdk package was excluded. > > So while there may be a bug here around package groups, for this particular > customer, i'd recommend changing their filter to include the epcoh "1" at > the front of the version string, and then i think everything will work for > them. > > Justin About, ~~ Satellite 6.10 does not include a package group unless all its packages are present ~~ True and that is the main concern raised by the end users. About, ~~ It turns out that these packages are using an epoch: java-11-openjdk-1:11.0.8.10-1.el7.x86_64 So changing this to 1:11.0.13.0.8-1.el7_9 caused everything to work properly, as '11.0.13.0.8-1.el7_9' was assuming a zero epoch, which meant that every java-11-openjdk package was excluded ~~ I got their issue fixed in a different way i.e. to exclude the kickstart repo itself from the filter but I can suggest this as well. But here's what the concern is from a user's point of view: A) Not everyone is possibly aware of the fact that there may or may not be an epoch release associated with a package version and we should not expect them to do so. B) We don't particularly explain this fact in Satellite 6.10 docs that they need to take the epoch release into consideration while applying package filters. Obviously, we can say, It's common sense to do so but we should not expect that all users have the same amount of knowledge around how epoch release is associated with rpm versioning and works. So this part needs to be improved via documentation or KCS. I will see what can be done here. But the main point remains that there is a behavioral change present. Both of the customers used two different filters (not explicitly java) and the same filter which had worked for 6.9 had stopped showing the package groups in 6.10. Thanks again for quickly looking into this.
*** Bug 2053410 has been marked as a duplicate of this bug. ***
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/34399 has been resolved.
Hello the summary includes the words "after upgrading to Satellite 6.10", but the steps in comment 0 do not say you need to update the 6.9 system to see the problem. Comment 1 also implies the problem will be there on a 6.10.1 system even if its a new install. Agreed? thank you
correct, no upgrade needed. It is reproducible on a fresh install of 6.10. I think comment 0 is just indicating a change in behavior.
(In reply to Justin Sherrill from comment #12) > correct, no upgrade needed. It is reproducible on a fresh install of 6.10. > I think comment 0 is just indicating a change in behavior. Thank you
1. Import manifest 2. Enabled and sync the two repos: Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server Red Hat Enterprise Linux 7 Server Kickstart x86_64 7.9 3. Create a CV and add the repos from step 2 4. Create an exclude RPM filter: --------|-----------|--------------------------|-------------------- RULE ID | FILTER ID | NAME | MINIMUM VERSION --------|-----------|--------------------------|-------------------- 1 | 1 | java-11-openjdk | 11.0.13.0.8-1.el7_9 2 | 1 | java-11-openjdk-headless | 11.0.13.0.8-1.el7_9 --------|-----------|--------------------------|-------------------- 5. Check package group information: # hammer package-group list --content-view-id <id> --search "name = Base" Expected: The package groups should not be missing from the CV even if a related package is being excluded. Actual: The package groups is not missing from the CV even if a related package is being excluded. ----|--------------------|--------------------------------------------------------|----------------------------------------------------------------------------- ID | PACKAGE GROUP NAME | REPOSITORY NAME | UUID ----|--------------------|--------------------------------------------------------|----------------------------------------------------------------------------- 135 | Base | Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server | /pulp/api/v3/content/rpm/packagegroups/d1da0a16-8408-4bc7-adc2-74e085b8b592/ 52 | Base | Red Hat Enterprise Linux 7 Server Kickstart x86_64 7.9 | /pulp/api/v3/content/rpm/packagegroups/ef49a7bf-5910-4420-9117-f4ab3e5b9396/ ----|--------------------|--------------------------------------------------------|----------------------------------------------------------------------------- Verified on 6.11_snap 14 with rubygem-katello-4.3.0.11-2.el8sat.noarch on both RHEL7.9 and RHEL8.5
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 (Moderate: Satellite 6.11 Release), 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/RHSA-2022:5498