<div dir="ltr"><div dir="ltr">I wrote up the story on switching publications to Master/Detail and removing publishers.  <a href="https://pulp.plan.io/issues/4678">https://pulp.plan.io/issues/4678</a></div><div dir="ltr"><br></div><div>Please read it through and ask questions. I believe adding it can be done in a backwards compatible way so it's addition in maybe rc2 shouldn't be disruptive. The disruptive part will be if Publishers get removed after that (see last paragraph on ticket), but we could plan that removal for rc3 perhaps and mark Publisher codepaths as deprecated in rc2.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 11, 2019 at 10:38 AM Dennis Kliban <<a href="mailto:dkliban@redhat.com">dkliban@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>The docker plugin is going to get rid of Publishers and Publications[0]. We are planning to update the DockerDistribution with a 'RepositoryVersion' field. If any other plugins want to do the same thing, we will need to make a change in pulpcore to the Distribution model. <br></div><div><br></div><div>[0] <a href="https://pulp.plan.io/issues/4669" target="_blank">https://pulp.plan.io/issues/4669</a><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 8, 2019 at 4:44 PM Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Thank you for writing this out. The most significant issue I read in this is that 3 of the 9 plugins are having their users take steps that aren't adding any value in their workflow. They want to (and have an opportunity to) take repository version content and expose it directly. They don't need Publications or Publishers. If they need no metadata, instead of a "pass-through" publication it would be easier to have a Distribution refer to a RepositoryVersion directly and remove the "pass-through" feature. They the user could skip this step ( <a href="https://github.com/pulp/pulp_ansible#create-a-publication" target="_blank">https://github.com/pulp/pulp_ansible#create-a-publication</a> ) and instead post the RepositoryVersion reference as part of the Distributor itself ( <a href="https://github.com/pulp/pulp_ansible#create-a-distribution-for-the-publication" target="_blank">https://github.com/pulp/pulp_ansible#create-a-distribution-for-the-publication</a> ).<br></div><div><br></div><div>The second issue I read here is that having users CRUD a publisher and then call that publisher is not as helpful/useful as CRUDing the resulting Publication directly. One practical issue related to this is the saving of the "publish" parameters. How do we store those over time? Our modeling choices have made this a bit challenging because Publication's aren't plugin controlled. A simple remedy is to have plugins provide various Publication objects instead of Publishers. These Publications would be managed by Master/Detail and when created it would run the task that creates the Publication and return the 202. This simplifies Pulp in that the options that were used to create the publication can be saved on the Publication as provided by various plugins. It also allows users to take one less step (they don't need to make a publisher to then make a publication). Instead users that need metadata generated can do so with one step, making the publication. So my main question is, can anyone remember why we didn't use Master/Detail in this area originally?<br></div><div><br></div><div>I believe these are changes we should explore. The top one is a pretty simple add on and mostly not a breaking change. The bottom one would be a larger change, but one that I believe we could make and should seriously consider pre 3.0 GA.</div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 8, 2019 at 7:42 AM Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>TLDR: <br></div><div><br></div><div>Auto-distribution of publications is performed implicitly instead of explicitly. <br></div><div>Plugins that don't generate metadata during publish have to provide a generic publisher.</div><div></div><div>Users have to keep track of publishers to make sure auto-distribution of new publications works.<br></div><div><br></div><div>More background:<br></div><div><br></div><div>Publishers in Pulp 3 serve three distinct functions: <br></div><div>  - store configuration for how a publication should be created</div><div>  - create publications using the configuration</div><div>  - update any distributions that are supposed to be auto updated with new publications of a repository (auto distribution). <br></div><div><br></div><div>Ansible, Docker, and Maven plugins do not generate any metadata when creating a publication. So their publishers don't need to store any configuration. Users of these plugins only get two benefits from publishers:</div><div><div>  - create publications using the configuration</div><div>  - update any distributions that are supposed to be auto updated with new publications of a repository (auto distribution). <br></div><div><br></div><div>The publications created by the publishers of these plugins could be created using a single generic publish task. So the only remaining benefit of a publisher for these plugins is the auto-distiribution that occurs when a Distribution has a repository and a pubisher configured. The only way this feature is documented right now is with the help text on the 'repository' and 'publisher' fields of Distributions. <br></div><div><br></div><div>Does anyone else see these as problems with the Publishers? <br></div></div></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>