Description of problem: When creating a content view filter for a package by name, I can see mixed results with the filter working as expected due to packages being modular and not being considered for RPM content view filters. A better representation of what packages would be affected by a filter or certain type should be created. Version-Release number of selected component (if applicable): satellite-6.12.0-4.el8sat.noarch How reproducible: Every time Steps to Reproduce: 1. Create a content view with rhel-7-server-rpms repo only and add the filter to exclude RPM "389-ds-base". At the time of this writing, this filters out 55 packages which would be correct. 2. Create another content view with the "Red Hat Satellite Maintenance 6.12 for RHEL 8 x86_64 RPMs" with a filter to exclude package "rubygem-clamp" (all archs, all versions). This filters out nothing. Create another filter for this same content view and filter out "*" for the package name (all archs, all versions) and it filters out only "satellite-clone". 3.This is because all packages in the Satellite Maintenance 6.12 for RHEL 8 (at this time) are modular except for 1 (satellite-clone). This is not explained or understandable from the content view filter screen without having to navigate to other pages on the Satellite. Actual results: See "Steps to reproduce" Expected results: {BEST OPTION} Inclusion/Exclusion should be applied to the repository no matter what the status of modularity or repository contains the stream its associated with. {NEXT BEST OPTION} WebUI should display the package's modularity status along with the stream they are associated with everywhere it's viewable to see packages: - https://satelite.example.com/content_views/:content_view_id/versions/:version_id/rpmPackages - https://satelite.example.com/packages - https://satelite.example.com/products/:product_id/repositories/:repository_id - etc Additional info: With the introduction of streams and modularity in RHEL 8 there has been a lot of confusion on why won't systems just update to the latest like yum always has. If DNF is going to treat RPMs differently at the OS level I believe Satellite should also reclass them as a "modular package" as opposed to including them under the umbrella term of "packages".
Looks like it's user error on my part. The packages are modular so they are not filtered out by the RPM filter: # curl https://bombsat612.d.sysmgmt.cee.redhat.com/katello/api/packages/?repository_id=4 | json_reformat | grep -e \"name -e modular "name": "rubygem-clamp", "modular": true, "name": "rubygem-foreman_maintain", "modular": true, "name": "rubygem-highline", "modular": true, "name": "satellite-clone", "modular": false, "name": "satellite-maintain", "modular": true, With this point brought up though, this repository is a dependency repository for the Satellite-Capsule 6 and Satellite 6 repositories. The streams don't actually live in the "Red Hat Satellite Maintenance 6.12 for RHEL 8 x86_64 RPMs", so there is no stream to filter out as well. I understand this is probably a very specific use case and probably not reproducible from any other repository offered by Red Hat, but as a user without intimate knowledge of modules I would have the following question: - As a user, how would I know my filter is working correctly for a repository (Red Hat or 3rd party) to remove packages if one does not fully understand modules, streams, cross repository dependency for a repository listed as having packages and no module streams and having packages that are modular? (In the Satellite WebUI it shows the "Red Hat Satellite Maintenance 6.12 for RHEL 8 x86_64 RPMs" as having 5 packages (as of today) and 0 module streams.) - Outside of the API example above and the package search page on the WebUI, how could a user know (preferably from the CV filter screen) that these packages are unaffected by the filter because they are listed as modules and also not affected by module stream filters because they are dependencies of another repository's stream? **Changing this to an RFE to provide better visual understanding for module packages unaffected by content view filters**
Based on the discussion last week we need to add some helper text. 1. When opening a Matching content modal, add a sentence to the empty state: "Package filters don’t apply to modular packages." 2. Add a question mark icon to the matching content modal(see https://www.patternfly.org/components/modal/design-guidelines#modals-with-help) with a helper text: "Matching RPMs based on your created filter rule. Remember, package filters don't apply to modular packages." 3. Add a question mark icon to the Create filter with a helper text: "Use filters to include or restrict certain content. When selecting RPMs, be aware that, package filters don't apply to modular packages." Pinging doc team to check the microcopy @bangelic
3. Add a question mark icon to the Create filter with a helper text: "Use filters to include or restrict certain content. When selecting RPMs, be aware that, package filters don't apply to modular packages." Remove extra comma so that it reads: "Use filters to include or restrict certain content. When selecting RPMs, be aware that package filters don't apply to modular packages."
Created redmine issue https://projects.theforeman.org/issues/36683 from this bug