Project

Profile

Help

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.

Back