Pulp

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.