Story #4678
Updated by bmbouter over 5 years ago
h3. Problem 1: unnecessary calls
As discussed "on the pulp-dev list":https://www.redhat.com/archives/pulp-dev/2019-April/msg00038.html 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":https://github.com/pulp/pulpcore/blob/master/pulpcore/app/viewsets/publication.py#L28 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":https://github.com/pulp/pulp_ansible/blob/master/pulp_ansible/app/viewsets.py#L124 does.
h3. 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/
h3. 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.
h3. Master/Detail Publication
We will have the Master/Detail Publication viewset overridden by the plugin and have the <code>def create()</code> method call the custom task with any number of arguments. This also resolves the saving of publication attributes.
.