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.
[0] https://pulp.plan.io/issues/4669 On Mon, Apr 8, 2019 at 4:44 PM Brian Bouterse <bbout...@redhat.com> wrote: > 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 ( > https://github.com/pulp/pulp_ansible#create-a-publication ) and instead > post the RepositoryVersion reference as part of the Distributor itself ( > https://github.com/pulp/pulp_ansible#create-a-distribution-for-the-publication > ). > > 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? > > 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. > > > > On Mon, Apr 8, 2019 at 7:42 AM Dennis Kliban <dkli...@redhat.com> wrote: > >> TLDR: >> >> Auto-distribution of publications is performed implicitly instead of >> explicitly. >> Plugins that don't generate metadata during publish have to provide a >> generic publisher. >> Users have to keep track of publishers to make sure auto-distribution of >> new publications works. >> >> More background: >> >> Publishers in Pulp 3 serve three distinct functions: >> - store configuration for how a publication should be created >> - create publications using the configuration >> - update any distributions that are supposed to be auto updated with >> new publications of a repository (auto distribution). >> >> 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: >> - create publications using the configuration >> - update any distributions that are supposed to be auto updated with >> new publications of a repository (auto distribution). >> >> 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. >> >> Does anyone else see these as problems with the Publishers? >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
