Project

Profile

Help

Story #4832

As a user, I can filter all repo versions by content unit

Added by daviddavis over 1 year ago. Updated about 1 month ago.

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

0%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Quarter:
Q1-2021

Description

If you want to delete a content unit, there's no way to check which repo versions it belongs to. This means that deleting content is virtually impossible.

We need to give users a way to filter repo versions by content. The problem is that there is no global repo version endpoint--repo versions are nested under repos.


Related issues

Related to Pulp - Story #4831: As a user, I have docs on how to delete contentASSIGNED

<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

History

#1 Updated by daviddavis over 1 year ago

  • Related to Story #4831: As a user, I have docs on how to delete content added

#2 Updated by daviddavis over 1 year ago

  • Subject changed from As a user, I can filter repo versions by content unit to As a user, I can filter all repo versions by content unit

Looks like there's a repo version filter already for filtering by content:

https://github.com/pulp/pulpcore/blob/master/pulpcore/app/viewsets/repository.py#L96

The only problem is that this is nested under repos.

#3 Updated by amacdona@redhat.com over 1 year ago

I am not very fond of the idea that users will need to "delete history" and remove all versions that contained a particular content unit jsut to remove it. As an alternative, I think it would be nice to add a boolean field to content like `disable_distribution`, which will allow the content to be added/removed from repository versions, but will not be served by the content app. Perhaps disabled content should be omitted from publications as well on a plugin-to-plugin basis.

Heres an example of why this is preferable. Say repo x is published and distributed in production, and one of the packages is determined to have a major security flaw. This package has been in the repository since the beginning. Is the user now expected to completely wipe all their history just to prevent the content from being distributed?

#4 Updated by daviddavis over 1 year ago

@asmacdo, I think your point makes sense. Let me give another example though: a user uploaded a package with sensitive information like customer info or a password. Even git lets you rewrite history to remove stuff. It's painful but possible.

Also, this story isn't entirely tied to deletion. What if a user wants to see how many/which repo versions have a particular content unit? Like in the case they're doing a security audit or something.

#5 Updated by amacdona@redhat.com over 1 year ago

+1 this story is necessary even outside of the content unit deletion use case.

#6 Updated by bmbouter over 1 year ago

I think there are several use cases here and we probably need a variety of mechanisms to cover them all.

1. A security-unsafe package is in Pulp and must be removed. We gotta get it out, quickly, and no matter what.
2. Which repo versions contain unit X?
3. Where is unit x being served right now?

What other aspects of this area could we consider use cases? What about ^ use cases, do they make any sense?

#7 Updated by daviddavis about 1 year ago

  • Sprint/Milestone deleted (3.0.0)

#8 Updated by dkliban@redhat.com about 1 month ago

Here are some options for implementing this:

  1. A new API endpoint at /pulp/api/v3/content-search/

  2. An additional GET parameter for the /pulp/api/v3/content/// endpoint. When 'include_repository_versions' is set to 'true', a 'repository_versions' list will be populated for each content requested.

I am in favor of number 2.

#9 Updated by daviddavis about 1 month ago

wrote:

Here are some options for implementing this:

  1. A new API endpoint at /pulp/api/v3/content-search/

  2. An additional GET parameter for the /pulp/api/v3/content/// endpoint. When 'include_repository_versions' is set to 'true', a 'repository_versions' list will be populated for each content requested.

I am in favor of number 2.

For option one, I'm not sure how this would work. Would this return content units or repository versions? I would expect it to return the former but then I am not sure how we'd know which repository versions a content unit belongs to unless we list the repo versions for each content unit. If we do that though, calling this endpoint would be extremely expensive as content units could belong to hundreds or thousands of repo verisons.

For option two, would this repository_versions field always be visible regardless of whether include_repository_versions is supplied or not? I seem to remember some problems in the api/bindings with response objects having optional fields.

I'd also like to call out a third option: having a repo version search endpoint that searches across repositories and accepts a content unit href. I think this would be useful for other potential use cases outside of this one.

#10 Updated by ipanova@redhat.com about 1 month ago

daviddavis wrote:

wrote:

Here are some options for implementing this:

  1. A new API endpoint at /pulp/api/v3/content-search/

  2. An additional GET parameter for the /pulp/api/v3/content/// endpoint. When 'include_repository_versions' is set to 'true', a 'repository_versions' list will be populated for each content requested.

I am in favor of number 2.

For option one, I'm not sure how this would work. Would this return content units or repository versions? I would expect it to return the former but then I am not sure how we'd know which repository versions a content unit belongs to unless we list the repo versions for each content unit. If we do that though, calling this endpoint would be extremely expensive as content units could belong to hundreds or thousands of repo verisons.

For option two, would this repository_versions field always be visible regardless of whether include_repository_versions is supplied or not? I seem to remember some problems in the api/bindings with response objects having optional fields.

I'd also like to call out a third option: having a repo version search endpoint that searches across repositories and accepts a content unit href. I think this would be useful for other potential use cases outside of this one.

I think it will extremely simplify our life if we filter only by one content unit and not set of them, otherwise we'd need to provide some sort of mapping.

How do you image that endpoint? GET /pulp/api/v3/repositories/versions/?content_unit_href=/pulp/api/v3/content/rpm/rpm/d17b1f9a-093f-49e1-b486-a993f0054b05/ or rather a POST one?

#11 Updated by daviddavis about 1 month ago

@ipanova, Yes or maybe /pulp/api/v3/repository_versions/ or /pulp/api/v3/repository-versions/.

#12 Updated by ipanova@redhat.com about 1 month ago

daviddavis wrote:

@ipanova, Yes or maybe /pulp/api/v3/repository_versions/ or /pulp/api/v3/repository-versions/.

sounds good, i'm on-board

#13 Updated by ipanova@redhat.com about 1 month ago

  • Quarter set to Q1-2021

Please register to edit this issue

Also available in: Atom PDF