Project

Profile

Help

Story #5708

closed

Allow operation specific plugin-input for validation and/or content modification

Added by bmbouter over 4 years ago. Updated over 3 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Quarter:

Description

Motivation

Plugins have a need to provide RepositoryVersion validation and/or modification for specific operations but not others. For example, for the pulp_rpm sync case, it's not important to check modulemd consistency, while for "modify" it's critical.

The RepositoryVersion.finalize_new_version runs with all operations so it's not viable to put operation-specific code there.

Design

Add a class attribute named PLUGIN_VALIDATE_MODIFY to the following core-provided objects and have it default to None. Then a plugin writer would subclass the object and specify the callable on their subclass.

  • DeclarativeVersion
  • SingleContentArtifactUploadSerializer
  • ModifyRepositoryActionMixin

The PLUGIN_VALIDATE_MODIFY callable must accept a single argument, new_version so it has the reference to the RepositoryVersion it should validate/modify.

Note these new operation-specific validation should be called before the Repository.finalize_new_version

Actions #1

Updated by daviddavis over 4 years ago

For example, for the pulp_rpm sync case, it's not important to check modulemd consistency

I want to give a longer description of the problem because it's not a lack of importance. Rather, the problem is that consistency with the remote repo should trump modulemd consistency and we have no way of solving this without context. During sync (as opposed to modify) we shouldn't remove module packages as they could still remain in the remote repo even if the module has been removed from the remote repo.

To illustrate, suppose a remote repo has module A which includes package X and module A gets removed from the upstream repo but package X remains. During sync, our current code would remove package X along with module A which would make it inconsistent with the remote repo. The problem is that our remove module packages code always runs but it should probably only run for modify and not sync.

Actions #2

Updated by dkliban@redhat.com over 3 years ago

  • Status changed from NEW to CLOSED - CURRENTRELEASE

Also available in: Atom PDF