Story #4678
Updated by ipanova@redhat.com 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. 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 Removal of publishers 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.
.