Project

Profile

Help

Issue #4644

Modular and RPM Errata Copy Documentation can be misleading of intended expected behavior

Added by bherring 7 months ago. Updated 5 months ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
Start date:
Due date:
Severity:
2. Medium
Version:
Platform Release:
2.19.1
Blocks Release:
OS:
Backwards Incompatible:
No
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Documentation, Pulp 2
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
Yes
Sprint:
Sprint 52

Description

Problem

A customer and internally with QE Testing of Modular and RPM Errata, there are questions about the behavior or copying Modular or RPM Errata from Source to Destination.

Proposed Action

There is really good documentation and examples here [1] for RPM and Errata cases with `--recursive` and `--recursive_conservative` methodologies, scenarios, and expected outcomes.

For RPM and Modular Errata copy, it would be good to have (1) more similar example, with visual example, stating that for any Errata Copy, all Errata, Modules, and RPM associated with that Errata will ALWAYS be coped -- no matter if there is an older/same Erratum/Module/RPM on the Destination or not.

Additional Notes

In 2.19.0+, the observed behavior matches the expected behavior:

Test scenario copying modular errata from repo A to repo B - repo B has an older version of the duck. duck-0.6. 

Copied Errata is RHEA-2012:0059 and, this errata is providing a newer version of duck. duck-0.7-1.noarch.rpm, from pulp-fixtures [2]

---
pulp-admin login -u admin -p admin
pulp-admin rpm repo create --repo-id foo --feed https://repos.fedorapeople.org/pulp/pulp/fixtures/rpm-with-modules/
pulp-admin rpm repo sync run --repo-id foo
pulp-admin repo list
pulp-admin rpm repo create --repo-id bar
pulp-admin rpm repo copy errata --str-eq="errata_id=RHEA-2012:0059" --from-repo-id=foo --to-repo-id=bar --recursive-conservative
pulp-admin repo list
---

1 - recursive True, recursive_conservative False

duck versions ['0.6', '0.7']

'content_unit_counts': {'erratum': 1, 'modulemd': 2, 'rpm': 3},

 2 - recursive False, recursive_conservative True

duck versions ['0.6', '0.7']

'content_unit_counts': {'erratum': 1, 'modulemd': 2, 'rpm': 3},

3 - recursive True, recursive_conservative True

duck versions ['0.6', '0.7']

'content_unit_counts': {'erratum': 1, 'modulemd': 2, 'rpm': 3},

I talked with Tanya as well, she pointed out the documentation section [2], (I read it before, but it was much clear after I talked with her), basically for modular erratums all modules, and rpms should be copied, and that is what Pulp is currently doing. 

Additional Testing

Pulp QE believes the scenarios needed to cover this query already exist. However, if there is a concern that additional cases would be useful, please feel free to create a dependent Test Tracker with additional scenarios.

References

[1] - https://docs.pulpproject.org/en/2.19/testing/plugins/pulp_rpm/user-guide/features.html?highlight=recursive_conservative#erratum-and-related-rpms
[2] - https://repos.fedorapeople.org/pulp/pulp/fixtures/rpm-with-modules/

Associated revisions

Revision c90056a0 View on GitHub
Added by ttereshc 6 months ago

Add exapmles to clarify errata advanced copy cases

closes #4644
https://pulp.plan.io/issues/4644

Revision ac2c1f6f View on GitHub
Added by ttereshc 5 months ago

Add exapmles to clarify errata advanced copy cases

closes #4644
https://pulp.plan.io/issues/4644

(cherry picked from commit c90056a08fde03308825845e67c62867d8c0c0fe)

History

#1 Updated by ttereshc 6 months ago

  • Triaged changed from No to Yes
  • Sprint set to Sprint 51

#2 Updated by bmbouter 6 months ago

  • Tags Pulp 2 added

#3 Updated by daviddavis 6 months ago

  • Sprint changed from Sprint 51 to Sprint 52

#4 Updated by ttereshc 6 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to ttereshc

#5 Updated by ttereshc 6 months ago

  • Status changed from ASSIGNED to POST

#6 Updated by dkliban@redhat.com 6 months ago

  • Platform Release set to 2.19.1

#7 Updated by dkliban@redhat.com 6 months ago

  • Sprint/Milestone set to 2.19.1

#8 Updated by ttereshc 5 months ago

  • Status changed from POST to MODIFIED

#9 Updated by ttereshc 5 months ago

#10 Updated by dkliban@redhat.com 5 months ago

  • Status changed from MODIFIED to ON_QA

#11 Updated by dkliban@redhat.com 5 months ago

  • Status changed from ON_QA to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF