Project

Profile

Help

Story #8760

Task #8740: [EPIC] Publication based plugins should use either `distribution.repository` or `distribution.publication` but not both

Setup Content App to auto-distribute latest publication if `SomeDistribution.repository` is set

Added by bmbouter 4 months ago. Updated 4 months ago.

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

100%

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

Description

To allow plugins to not have auto-publish update distributions, the content app needs to "auto serve" the latest publication if SomeDistribution.repository is set.

Associated revisions

Revision 6b818191 View on GitHub
Added by gerrod 4 months ago

Content app auto-distributes latest publication

fixes: #8760 https://pulp.plan.io/issues/8760

History

#1 Updated by bmbouter 4 months ago

  • Sprint/Milestone set to 3.13.0

This is needed for plugins to use, so we want to get this into 3.13.

#2 Updated by gerrod 4 months ago

One potential problem I see is that plugins that use the autopublish feature are now putting the publish settings as fields on the repository. There can be multiple publications pointing to the same repository_version, but all with different publish settings and it doesn't seem possible to check those settings fields easily against the repository's current settings fields. Even if you do check them, that doesn't guarantee that those were the settings used at time of the publication creation, since you can update the repository's settings anytime you want, they are not tied to the repository_version. Currently I am assuming that the earliest created publication is the one made when the repository_version was created and the one the user wants to serve. If they manually set a distribution's repository field without having that repository use autopublish then this assumption might not be the best one to use when determining which publication to serve, i.e. you might want to choose the latest publication in that scenario. I think pulpcore should make the assumption that publication-based plugins distribution's repository field is used for autopublish and if a publish-based plugin wants to do something different then they need to take responsibility for breaking the assumption.

#3 Updated by dalley 4 months ago

gerrod the ${type}Publication itself generally has a copy of the exact settings it was created with. The fields on repository are just there for creating new ones, not as a historical record of what they were at the time.

e.g.

https://github.com/pulp/pulp_rpm/blob/master/pulp_rpm/app/models/repository.py#L429-L433

https://github.com/pulp/pulp_file/blob/master/pulp_file/app/models.py#L117

https://github.com/pulp/pulp_deb/blob/main/pulp_deb/app/models/publication.py#L33-L37

The Python plugin is weird in that it doesn't have any publish settings.

Those are set in the publish task, e.g. https://github.com/pulp/pulp_rpm/blob/master/pulp_rpm/app/tasks/publishing.py#L294-L304

So you shouldn't ever need to look at the repository to know what the publication settings were.

#4 Updated by pulpbot 4 months ago

  • Status changed from NEW to POST

#5 Updated by dalley 4 months ago

  • Assignee set to gerrod
  • Sprint set to Sprint 97

#6 Updated by gerrod 4 months ago

dalley wrote:

gerrod the ${type}Publication itself generally has a copy of the exact settings it was created with. The fields on repository are just there for creating new ones, not as a historical record of what they were at the time.

So you shouldn't ever need to look at the repository to know what the publication settings were.

dalley, The problem isn't finding out the settings the publication used, the problem is determining which publication should be served for a repository version when multiple publications with different settings can be used. The problem I am describing is all about intent. What criteria should auto-distribute use to determine which publication to serve? I am using the assumption that auto-distribute is going to be used with auto-publish and therefore should use the earliest publication created since auto-publish will create the first publication for a new repository version.

#7 Updated by dalley 4 months ago

Yeah, "newest" is about the best assumption we can make here.

We should probably add an index for that though, I don't think we have one.

#8 Updated by bmbouter 4 months ago

dalley wrote:

Yeah, "newest" is about the best assumption we can make here.

We should probably add an index for that though, I don't think we have one.

+1 to all this

#9 Updated by gerrod 4 months ago

  • Status changed from POST to MODIFIED
  • % Done changed from 0 to 100

#10 Updated by pulpbot 4 months ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF