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 ViewsAssignee: 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.4CC: iballou, jgao, sajha
Target Milestone: UnspecifiedKeywords: 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
Description of problem:

When creating an include filter with date range "unspecified date TO specific date", the errata count is correct but the package count is showing fewer than the actual count.

Steps to Reproduce:

1. Current status of the CV:

32991 Packages
4993 Errata ( 1101 3248 644 )

2. Create filter as follows:

 Type: Include Errata

 Start Date: Unspecified

 End date: Today(Jan 13,2023)

 Date Type: 'Updated on or Issued on'


3. Publish a new version.

4. Status after adding the filter and publishing a new version:

28360 Packages
4993 Errata ( 1101 3248 644 )


Actual results:

Fewer package count with include filter.

Expected results:

Package count should not be altered as not specifying the start date and end date selected is today.

Comment 1 Samir Jha 2023-05-09 14:14:48 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?

Comment 7 J Gao 2024-03-21 17:56:37 UTC
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.

Comment 8 Samir Jha 2024-03-22 00:16:17 UTC
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.

Comment 9 J Gao 2024-03-22 18:36:06 UTC
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
----------|------------------------------------|-------------|----------|----------

Comment 10 Ian Ballou 2024-05-06 18:34:34 UTC
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.

Comment 11 Ian Ballou 2024-05-06 18:55:02 UTC
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.

Comment 12 Ian Ballou 2024-05-06 18:59:18 UTC
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.

Comment 13 Ian Ballou 2024-05-06 19:22:49 UTC
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.

Comment 14 Eric Helms 2024-06-06 16:05:03 UTC
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.

Comment 15 Red Hat Bugzilla 2024-10-05 04:25:46 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days