Project

Profile

Help

Story #4678

closed

As a plugin writer, I have Master/Detail Publications

Added by bmbouter almost 5 years ago. Updated over 4 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 1: unnecessary calls

As discussed on the pulp-dev list one issue is that users want to make a Publication, but to do so they first have to make a Publisher. This creates several downsides:

a) it introduces a concept the user and workflow performs but doesn't need, the creation of a Publisher.
b) The user has to CRUD and manager their publishers and their publications, when they just want publications
c) it requires plugin writers to provide a publisher when neither they or they users need one

Currently the Publication viewset is provided by core and provides Read, List, and Delete but not create, you have to either use a Publisher or the plugin provides its own viewset for Publications like pulp_ansible does.

Problem 2: plugin writers can't record extra parameters on how the Publication was made

Since Publication's are never subclassed they cannot have extra plugin-defined attributes on them.

The user would create the file plugin for example at:

/pulp/api/v3/publications/file/file/

Solution

Allow the Publication endpoint to be POST and have it create the publication via a task that the user can monitor. This will be on a Publication which would be Master/Detail provided by core similar to how Remote's are provided. This resolves problem 1 because plugins can have their users POST to publications as 1 call instead of 2.

Switching to Master/Detail allows plugins to define additional attributes as desired which resolves problem 2.

Master/Detail Publication

We will have the Master/Detail Publication viewset overridden by the plugin and have the def create() method call the custom task with any number of arguments. This also resolves the saving of publication attributes.


Related issues

Related to Ansible Plugin - Story #4701: As a user my publication creation use Master/Detail provided by coreCLOSED - CURRENTRELEASEdaviddavis

Actions
Related to Pulp - Task #4715: Remove 'publisher', 'publication', and 'repository' from BaseDistributionCLOSED - CURRENTRELEASEgmbnomis

Actions
Related to Pulp - Task #4724: Add PublicationsCLOSED - CURRENTRELEASE

Actions
Has duplicate Pulp - Story #4647: As a user, I can create a plugin specific publication using /pulp/api/v3/publications/<plugin>/ endpointCLOSED - DUPLICATE

Actions
Blocks Python Support - Refactor #4699: As a user, I can create a Python PublicationMODIFIEDamacdona@redhat.com

Actions
Blocks File Support - Task #4720: Remove publishers from pulp_fileCLOSED - CURRENTRELEASEdaviddavis

Actions
Actions #1

Updated by bmbouter almost 5 years ago

  • Description updated (diff)

added timeline info

Actions #2

Updated by dkliban@redhat.com almost 5 years ago

  • Has duplicate Story #4647: As a user, I can create a plugin specific publication using /pulp/api/v3/publications/<plugin>/ endpoint added
Actions #3

Updated by bmbouter almost 5 years ago

  • Description updated (diff)
Actions #4

Updated by daviddavis almost 5 years ago

This all sounds good to me. I'm a bit mixed about removing publishers because I don't think they are going to be used that often and having them in core doesn't provide that much value to plugin writers.

Actions #5

Updated by daviddavis almost 5 years ago

  • Sprint/Milestone set to 3.0.0

Setting the 3.0 milestone since this'll likely need to be addressed before GA.

Actions #6

Updated by bmbouter almost 5 years ago

During post-triage discussion @asmacdo identified the use case where a user doesn't want to provide repetitive options over and over and in that case specifically a publisher is useful. The downside of keeping publishers is that almost no one will use them and few plugins will even provide them, but in the spirit of small change I am removing the publisher removal from this story at least.

Actions #7

Updated by ipanova@redhat.com almost 5 years ago

  • Description updated (diff)
Actions #8

Updated by ipanova@redhat.com almost 5 years ago

  • Description updated (diff)
Actions #9

Updated by amacdona@redhat.com almost 5 years ago

  • Blocks Refactor #4699: As a user, I can create a Python Publication added
Actions #10

Updated by bmbouter almost 5 years ago

  • Related to Story #4701: As a user my publication creation use Master/Detail provided by core added
Actions #11

Updated by daviddavis almost 5 years ago

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

Updated by bmbouter almost 5 years ago

  • Description updated (diff)

adding url example

Actions #13

Updated by amacdona@redhat.com almost 5 years ago

  • Related to Task #4715: Remove 'publisher', 'publication', and 'repository' from BaseDistribution added
Actions #14

Updated by ipanova@redhat.com almost 5 years ago

  • Sprint set to Sprint 52
Actions #15

Updated by daviddavis almost 5 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to daviddavis
Actions #16

Updated by bmbouter almost 5 years ago

  • Blocks Task #4720: Remove publishers from pulp_file added
Actions #17

Updated by daviddavis almost 5 years ago

With this change, publications in the database become typed. The question is how do I fill in the values for '_type' for existing publications? Or do we not support upgrades and require users to redo their database in the next RC release.

Actions #18

Updated by bmbouter almost 5 years ago

I think opting to provide no migration and having users redo their dbs in the next release is the best path personally.

Actions #19

Updated by daviddavis almost 5 years ago

+1. I am going to redo the migration in core as well since users are redoing their databases.

Actions #20

Updated by daviddavis almost 5 years ago

Actions #21

Updated by daviddavis almost 5 years ago

  • Status changed from ASSIGNED to POST
Actions #22

Updated by daviddavis almost 5 years ago

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

Updated by daviddavis almost 5 years ago

  • Status changed from MODIFIED to POST
Actions #24

Updated by bmbouter almost 5 years ago

  • Tags deleted (Pulp 3)
Actions #25

Updated by daviddavis almost 5 years ago

  • Status changed from POST to MODIFIED
Actions #26

Updated by bmbouter over 4 years ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Also available in: Atom PDF