Project

Profile

Help

Story #4745

closed

As a plugin writer, I can create distributions for repository versions

Added by daviddavis over 5 years ago. Updated almost 5 years ago.

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

100%

Estimated time:
Platform Release:
Groomed:
Yes
Sprint Candidate:
Yes
Tags:
Sprint:
Sprint 52
Quarter:

Description

Problem

Some plugins like pulp_ansible and pulp_docker have no need for publications since they don't use metadata. Give these plugins a way to attach distributions directly to repo versions.

Solution

1. Add a "repository_version" attribute to the Distribution model
2. Update the content app to serve up content from that RepositoryVersion
3. The "repository_version" and "publication" fields should not be used together and should error somehow.

We will also remove the 'publisher' option because we expect it will not be used in 3.0 and will introduce more confusion than value.

We will also adjust the auto-distribution behavior as follows:

When the Distribution.repository field is set, the Distribution will be updated to have the repository_verison field point at the newly created repository_version.


Related issues

Blocks Pulp - Story #4680: As a user I have lifecycle docs in pulpcore workflowsCLOSED - CURRENTRELEASE

Actions
Blocks Ansible Plugin - Task #4765: Remove PublicationsCLOSED - CURRENTRELEASEdaviddavis

Actions
Blocked by Pulp - Issue #4791: Cannot `make diagrams` on F29 w/ pulpliftCLOSED - CURRENTRELEASEbmbouterActions
Actions #1

Updated by amacdona@redhat.com over 5 years ago

This won't actually help docker, since docker has its own implementation of distributions. But +1 to this idea for the general case

Actions #2

Updated by bmbouter over 5 years ago

I think pass-through is still useful because in cases where you have metadata and a huge number of artifacts you just want to let the repo version handle the rest. The think that doesn't seem as useful is having PublishedArtifact at all but I'm not proposing we get rid of it.

+1 to this story. We need to have a technical proposal on how to implement.

Actions #3

Updated by bmbouter over 5 years ago

I think we should add a field to Distribution called "repository_version"https://github.com/pulp/pulpcore/blob/6eef8fc14df37a4e1f52af53848b5cb75f08a736/pulpcore/app/models/publication.py#L248.

The "repository_version" and the "publication" field should not be used together. Having a distribution serve both content from a Repository Version and a Publication would be confusing and could lead to unexpected results.

Actions #4

Updated by amacdona@redhat.com over 5 years ago

Heres another question: How will autodistribution work? Should it just be repository based?

Actions #5

Updated by bmbouter over 5 years ago

I think the "respository" field should autodistribute whenever a new repo-version is made. Also the existing "publisher" field should continue to auto-distribute whenever it publishes a publication as it does today.

The change would be that today I think the repository and publisher field are used together. Will this change cause any problems?

Actions #6

Updated by amacdona@redhat.com over 5 years ago

  • Blocks Story #4680: As a user I have lifecycle docs in pulpcore workflows added
Actions #7

Updated by bmbouter over 5 years ago

  • Description updated (diff)

Removing some of the questions that were answered in comments and on irc.

Actions #8

Updated by bmbouter over 5 years ago

  • Description updated (diff)

Removing some of the questions that were answered in comments and on irc and rewriting with a full solution.

Actions #9

Updated by bmbouter over 5 years ago

Actions #10

Updated by dkliban@redhat.com over 5 years ago

bmbouter, take a look at what I did for pulp_docker to handle this use case: https://github.com/pulp/pulp_docker/pull/341/files

We use the serializer to enforce repository or repository version.

The content app does the auto distribution when repository is set. We added a method for looking up the latest repo version. So no extra updating of Distribution is needed at repo version creation time.

Actions #11

Updated by amacdona@redhat.com over 5 years ago

  • Groomed changed from No to Yes
  • Sprint Candidate changed from No to Yes
  • Sprint set to Sprint 52
Actions #12

Updated by bmbouter over 5 years ago

  • Description updated (diff)

updating description based on convo w/ other devs

Actions #13

Updated by bmbouter over 5 years ago

  • Status changed from NEW to POST
  • Assignee set to bmbouter
Actions #14

Updated by bmbouter over 5 years ago

  • Blocked by Issue #4791: Cannot `make diagrams` on F29 w/ pulplift added

Added by bmbouter over 5 years ago

Revision d75e94a5 | View on GitHub

Distributions serve RepositoryVersion

This adds the field 'repository_version' to a Distribution which will serve the content in that RepositoryVersion.

This also removes the 'publisher' field which was decided to no longer be something we want at this time.

It adds some docs in the workflow section that describing 3 auto-distribution workflows.

Lastly, it adjusts auto-distribution so that the 'repository' field will serve the latest RepositoryVersion automatically.

The 'repository', 'repository_version', and 'publication' fields cannot be used together.

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

Actions #15

Updated by bmbouter over 5 years ago

  • Status changed from POST to MODIFIED
  • % Done changed from 0 to 100
Actions #16

Updated by bmbouter over 5 years ago

  • Status changed from MODIFIED to POST

There is followon work for this so I need to move back to POST.

Actions #17

Updated by bmbouter over 5 years ago

  • Status changed from POST to MODIFIED

Actually this story is done, it was https://pulp.plan.io/issues/4785 that needed extra work.

Actions #18

Updated by bmbouter almost 5 years ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Also available in: Atom PDF