Bug 1954820

Summary:	pulp3_migration_stats rake task can underestimate the migration timing
Product:	Red Hat Satellite	Reporter:	Ian Ballou <iballou>
Component:	Repositories	Assignee:	Ian Ballou <iballou>
Status:	CLOSED ERRATA	QA Contact:	Cole Higgins <chiggins>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.9.0	CC:	egolov, ehelms, jjeffers, jsherril
Target Milestone:	6.9.4	Keywords:	Triaged, UserExperience
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	tfm-rubygem-katello-3.18.1.33-1	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1973344 (view as bug list)		Environment:
Last Closed:	2021-07-29 12:58:50 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 Ian Ballou 2021-04-28 19:57:48 UTC

Description of problem:

Internally, there is an error with the migration timing code that can cause a variable to go negative.  This can occur if the user has many on-demand repositories that are included in content views.

The fix involves changing this line (https://github.com/Katello/katello/blob/KATELLO-3.18/lib/katello/tasks/pulp3_migration_stats.rake#L13) to be `Katello::RepositoryRpm.where(:repository_id => Katello::Repository.yum_type.on_demand).select(:rpm_id).distinct.count`.

Version-Release number of selected component (if applicable):

6.9

How reproducible:

Always, if there are on-demand repositories inside of content views.

Steps to Reproduce:
1. Create any repository that is on-demand
2. Put that repository in a content view and publish it
3. Run `Katello::RepositoryRpm.where(:repository_id => Katello::Repository.yum_type.on_demand).distinct.count` in the foreman console and notice that it is negative.

Actual results:
The `on_demand_rpm_count` is negative, which causes the estimation time to be too low.

Expected results:
The `on_demand_rpm_count` is accurate.


Additional info:

Comment 1 Ian Ballou 2021-04-28 19:59:54 UTC

Created redmine issue https://projects.theforeman.org/issues/32449 from this bug

Comment 2 Bryan Kearney 2021-04-29 00:01:07 UTC

Upstream bug assigned to iballou

Comment 3 Bryan Kearney 2021-04-29 00:01:10 UTC

Upstream bug assigned to iballou

Comment 4 Ian Ballou 2021-05-06 21:14:47 UTC

Moving to POST since the upstream PR is merged.

Comment 5 Justin Sherrill 2021-06-01 19:49:30 UTC

this should not be on 6.10

Comment 8 Ian Ballou 2021-07-21 15:41:59 UTC

Correction to the original BZ notes: immediate_unmigrated_rpm_count was the variable that could go negative. Here's a good way to test:

1) Follow the original verification steps

2) Ensure that the following is negative:

```
::Katello::Rpm.count - Katello::RepositoryRpm.where(:repository_id => Katello::Repository.yum_type.on_demand).distinct.count
```

3) Ensure that the following is not negative:

```
::Katello::Rpm.count - Katello::RepositoryRpm.where(:repository_id => Katello::Repository.yum_type.on_demand).select(:rpm_id).distinct.count
```


Explanation:

The original on_demand_rpm_count query left out the `select(:rpm_id)` part, which would lead to on_demand_rpm_count being potentially way too large.  If on_demand_rpm_count is too big, and the user has not yet migrated any RPM content to Pulp 3, migrated_rpm_count would be zero. So, on_demand_unmigrated_rpm_count would equal on_demand_rpm_count, which is then also extremely large.  Therefore, immediate_unmigrated_rpm_count could be negative in the following equation since:
```
    immediate_unmigrated_rpm_count = ::Katello::Rpm.count - migrated_rpm_count - on_demand_unmigrated_rpm_count
```

on_demand_unmigrated_rpm_count is "extremely large", i.e., much greater than even ::Katello::Rpm.count.  migrated_rpm_count here is assumed to be zero, so that's how you get a negative number.

Comment 9 Ian Ballou 2021-07-21 17:58:32 UTC

Here's a way to test using the pulp3_migration_stats rake task directly:

Prerequisite: start on Satellite 6.9 with Pulp 2 enabled, not Pulp 3 (the default).


*** On a Satellite 6.9 machine without my commit:

1) Sync the recommended RHEL 8 BaseOS and AppStream repos on a 6.9 box using the on demand downlaod policy.
2) Put the repos in a content view and publish it
3) Run `foreman-rake katello:pulp3_migration_stats`:
  -> See that the rake task gives this output in the middle: Estimated migration time based on yum content: fewer than 5 minutes
    -> This is the bug. This is an under-estimate.



*** On a Satellite 6.9 machine with my commit:


1) Follow steps 1 through 3 above:
  -> See that the rake task gives this output in the middle: Estimated migration time based on yum content: 0 hours, 11 minutes

Comment 15 errata-xmlrpc 2021-07-29 12:58:50 UTC

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 (Satellite 6.9.4 Async Bug Fix Update), 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/RHBA-2021:2948

Comment 16 errata-xmlrpc 2021-07-29 13:02:56 UTC

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 (Satellite 6.9.4 Async Bug Fix Update), 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/RHBA-2021:2948