[Pulp-dev] Importer and Distributor Modeling

[Jeremy Cline]

On 09/06/2016 04:35 PM, Brian Bouterse wrote:
> The current Django modeled Importer [0] and Distributor [1] allow for
> these objects to be associated or unassociated with a repository. I'm
> familiar with the use cases that motivate associating a
> importer/distributor with a repository, but what are the use cases
> around an Importer/Distributor to exist without being associated with a
> repo? Is there something that we already do which would require this?

I have been bouncing a few ideas around how to unify a few things. We
currently have two sets of content catalogs: one for lazy sync, and one
for alternate content sources. We should really just maintain a single
catalog for *all* content we handle and that table should be designed
to support lazy sync, alternate content sources, content scrubbing, etc.
and it should *always* be built for any content we handle.

Alternate content sources lets you define a list of places content can
be obtained, and weights can be applied in order to prefer the least
expensive option. It requires that "catalogers" be made to inspect the
content source and decide what content is available for download. This
is very similar to an importer, which inspects a content source, decides
what to download, and then downloads it.

Wouldn't it be nice if you didn't have to write an importer *and* a
cataloger? Wouldn't it be better to just use an importer to generate
the catalog and skip downloading the content itself (and does that
feature sound familiar)? However these alternate content sources aren't
associated with repositories, so the importer can't be required to
relate to a repository.

As far as I know, there is no use-case for a distributor that isn't
attached to a repository. I believe the justification is that there's
a group distributor as well as a plain distributor, so there should be
an intermediate class. However, it is my opinion that we ax the group
distributor since it's used in a single place, the RPM export code, and
all it does is loop through a set of repositories and calls their
repository distributor (potentially with some override configuration).
This could be done so many other ways with less effort on our part that
I won't even bother to list them.

To summarize:

Let's just have an "Importer" that has an optional relation to a
repository.

Let's get rid of the GroupDistributor and turn the
"RepositoryDistributor" into just "Distributor".

-- 
Jeremy Cline
XMPP: jeremy at jcline.org
IRC:  jcline

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20160907/efa6fbdb/attachment.sig>