<div dir="ltr">I've also been eyeing the opportunity to combine the two catalogs. It makes a lot of sense.<div><br></div><div>And if we could reduce an importer's sync responsibility to just creating units and populating one catalog, and then let pulp do the downloading (at the appropriate time based on settings), that would give us a common pattern that most plugins could use.</div><div><br></div><div>I'll interested for Jeff to chime in with the reasoning behind the current Importer and Distributor model.</div><div><br></div><div>Michael </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 7, 2016 at 9:01 AM, Jeremy Cline <span dir="ltr"><<a href="mailto:jcline@redhat.com" target="_blank">jcline@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 09/06/2016 04:35 PM, Brian Bouterse wrote:<br>
> The current Django modeled Importer [0] and Distributor [1] allow for<br>
> these objects to be associated or unassociated with a repository. I'm<br>
> familiar with the use cases that motivate associating a<br>
> importer/distributor with a repository, but what are the use cases<br>
> around an Importer/Distributor to exist without being associated with a<br>
> repo? Is there something that we already do which would require this?<br>
<br>
</span>I have been bouncing a few ideas around how to unify a few things. We<br>
currently have two sets of content catalogs: one for lazy sync, and one<br>
for alternate content sources. We should really just maintain a single<br>
catalog for *all* content we handle and that table should be designed<br>
to support lazy sync, alternate content sources, content scrubbing, etc.<br>
and it should *always* be built for any content we handle.<br>
<br>
Alternate content sources lets you define a list of places content can<br>
be obtained, and weights can be applied in order to prefer the least<br>
expensive option. It requires that "catalogers" be made to inspect the<br>
content source and decide what content is available for download. This<br>
is very similar to an importer, which inspects a content source, decides<br>
what to download, and then downloads it.<br>
<br>
Wouldn't it be nice if you didn't have to write an importer *and* a<br>
cataloger? Wouldn't it be better to just use an importer to generate<br>
the catalog and skip downloading the content itself (and does that<br>
feature sound familiar)? However these alternate content sources aren't<br>
associated with repositories, so the importer can't be required to<br>
relate to a repository.<br>
<br>
As far as I know, there is no use-case for a distributor that isn't<br>
attached to a repository. I believe the justification is that there's<br>
a group distributor as well as a plain distributor, so there should be<br>
an intermediate class. However, it is my opinion that we ax the group<br>
distributor since it's used in a single place, the RPM export code, and<br>
all it does is loop through a set of repositories and calls their<br>
repository distributor (potentially with some override configuration).<br>
This could be done so many other ways with less effort on our part that<br>
I won't even bother to list them.<br>
<br>
To summarize:<br>
<br>
Let's just have an "Importer" that has an optional relation to a<br>
repository.<br>
<br>
Let's get rid of the GroupDistributor and turn the<br>
"RepositoryDistributor" into just "Distributor".<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Jeremy Cline<br>
XMPP: <a href="mailto:jeremy@jcline.org">jeremy@jcline.org</a><br>
IRC:  jcline<br>
<br>
</font></span><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>