Bug 2160804
| Summary: | Content view with include errata filter has fewer package count than expected | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | mithun kalyat <mkalyat> |
| Component: | Content Views | Assignee: | satellite6-bugs <satellite6-bugs> |
| Status: | CLOSED MIGRATED | QA Contact: | Satellite QE Team <sat-qe-bz-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.11.4 | CC: | iballou, jgao, sajha |
| Target Milestone: | Unspecified | Keywords: | MigratedToJIRA, 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-06-06 16:05:03 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
mithun kalyat
2023-01-13 18:46:33 UTC
When applying an errata filter, the new CV version by default will only have the errata and packages in the errata. I believe the difference in package count is from filtering out all packages not associated to any errata. To get all packages not associated to any errata, we require an empty RPM filter with `Include all RPMs not associated to any errata` flag set to true. Could you confirm that is also the behavior you are seeing? I am experience this bug on Satellite v6.14.2 as well. There is a Red Hat support ticket (case# 03763140) for this. I am using EPEL 8 repository and create a content view. Without any filter the CV shows there are 10049 RPM packages. After applied two filters: (1)[Include all RPMs not associated to any errata] RPM filter; (2) [Include errata with the end date set to March 11 2024], the total available package number drop to 4764! [root@foreman-006 ~]# hammer content-view version list --content-view 'cv_test_epel8' --organization 'myORG' ----|-------------------|---------|-------------------|----------------------- ID | NAME | VERSION | DESCRIPTION | LIFECYCLE ENVIRONMENTS ----|-------------------|---------|-------------------|----------------------- 135 | cv_test_epel8 7.0 | 7.0 | | Library 124 | cv_test_epel8 1.0 | 1.0 | No filter applied | ----|-------------------|---------|-------------------|----------------------- [root@foreman-006 ~]# hammer --csv --no-headers package list --content-view-version-id 124 --organization 'myORG' | wc -l 10049 [root@foreman-006 ~]# hammer --csv --no-headers package list --content-view-version-id 135 --organization 'myORG' | wc -l 4764 [root@foreman-006 ~]# Some popular packages, such as htop, is missing aster apply the two filters. Hello, For modular repos, EPEL in the instance above, 1. RPM filters only include non-modular packages. 2. Errata filters include packages (modular and non-modular) for included errata. 3. To get modular packages with no errata (That's the likely missing bunch of packages in the published version with the above 2 filters), create an include module stream filter with "Include all module streams not associated to any errata" checked. It seems the EPEL repository doesn't have any stream module. So adding a filter to include all stream module don't change anything. I tested it by added a 3rd Include filter for the stream module and it still missing lots of packages. [root@foreman-006 ~]# hammer content-view version list --content-view 'cv_test_epel8' --organization 'myORG' ----|--------------------|---------|-------------------|----------------------- ID | NAME | VERSION | DESCRIPTION | LIFECYCLE ENVIRONMENTS ----|--------------------|---------|-------------------|----------------------- 157 | cv_test_epel8 14.0 | 14.0 | | Library 148 | cv_test_epel8 10.0 | 10.0 | | 124 | cv_test_epel8 1.0 | 1.0 | No filter applied | ----|--------------------|---------|-------------------|----------------------- [root@foreman-006 ~]# hammer --csv --no-headers package list --content-view-version-id 157 --organization 'myORG' | wc -l 4764 [root@foreman-006 ~]# hammer content-view list | grep cv_test_epel8 37 | cv_test_epel8 | cv_test_epel8 | false | 2024/03/22 18:03:42 | 345 [root@foreman-006 ~]# hammer content-view filter list --content-view-id 37 ----------|------------------------------------|-------------|----------|---------- FILTER ID | NAME | DESCRIPTION | TYPE | INCLUSION ----------|------------------------------------|-------------|----------|---------- 73 | AllRPMs_NoErrata | | rpm | true 76 | AllStreams_NoErrata | | modulemd | true 74 | Errata (updated before 2024-03-11) | | erratum | true ----------|------------------------------------|-------------|----------|---------- I'm seeing a trend. For the errata excluded by EPEL erroneously, all have an erratum type of "Newpackage". This is a type that outside of the usual bugfix/security/enhancement. I think this is because we allow users to filter errata by type, which is likely built into Katello errata copying logic. So, the errata without one of the "normal" types get excluded. To solve this, we can change the errata filtering logic to include all unknown errata types if the errata filter doesn't specify certain types to filter. In the code, that means checking if all 3 normal types (security, enhancement, bugfix) are included on the content view filter rule. The best workaround I can think of is to have the erratum filter apply only to repositories other than the EPEL one. Also, "newpackage" isn't the only errata type to watch out for. There's also "unspecified". For the sake of this issue, we should assume that there could be an arbitrary amount of other errata types specified by the upstream repositories. The issue with what I mentioned in Comment 10 is that users who actually want to filter in only bugfix / enhancement / security errata will lose that capability, since it would be used as a marker for including all other errata types. I think we'll need to handle this case more carefully. Perhaps we could consider all errata that are not in the normal types list to have the errata type "other/unknown/etc". Then these other errata could be filtered just like the normal ones. Or, any extra errata types past the normal ones could be added to the list of errata types Satellite Katello knows about and allow filtering on each type independently. That would likely be more complex. @sajha I'm curious what you think about this idea. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days |