Story #4678

Updated by about 5 years ago

h3. 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. 

 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. Removal of publishers 

 We will remove them with the rc3 release and instead 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. attributes which is yet it's own problem for those who use publishers. 

 The Publishers API will be marked as deprecated asap and will be removed from the REST API in RC 3. (pulpcore 3.0.0rc3 and pulpcore-plugin 0.1.0rc3)