[Pulp-dev] Importer Name

[Jeff Ortel]

On 03/08/2018 10:13 AM, Austin Macdonald wrote:
> Motivation:
> The name "importer" carries some inaccurate implications.
> 1) Importers should "import". Tasks like "sync" will do the actual 
> importing. The object only holds the configuration that happens to be 
> used by sync tasks.
> 2) Sync tasks on mirror mode remove content as well as add it, so 
> "import" isn't quite right.
>
> Proposed name: Remote
>
> The inspiration for remote is "git remote". In git, remotes represent 
> external repositories, which is almost exactly what our importers do.

+1, The git/ostree "remote" concept applies very well to most of what an 
"importer" defines in pulp.

>
> -------------------------------------------------------
> Part 2: Trim the fields
>
> Currently, Importers have settings that can be categorized in 2 ways. 
> I am proposing removing the "sync settings" from the Remote model:
>
> External Source information
>     name
>     feed_url
>     validate
>     ssl_ca_certificate
>     ssl_client_certificate
>     ssl_client_key
>     ssl_validation
>     proxy_url
>     username
>     password
>
> Sync settings
>     download_policy
>     sync_mode
>
> This had some advantages when Importers were related to Repositories. 
> For example, having a repository.importer that always used the same 
> sync mode made sense. However, the "how" to sync settings don't make 
> much sense when importers and repositories are not linked. It seems 
> very reasonable that a user might have 2 repositories that sync from 
> the same source (ex EPEL). It does not make sense for them to have 
> create an Importer for the EPEL repository twice or more just to 
> change sync_mode or download policy. Instead of modeling these fields, 
> I propose that they should POST body parameters.

I, as a user, don't like having to specify download_policy & sync_mode 
on every request.  The burden on the user to passing these consistently 
seems unnecessary and prone to error.  And, like something that pulp 
should store as part of it's value proposition.   Imagine an 
organization with tons of repositories and admins. They would need to 
maintain a spreadsheet, notes, scripts for these settings so that admin 
A is syncing using the same settings as admin B.

Perhaps download_policy &  sync_mode should be attributes of the 
repository.  Thoughts on moving them there.  The sync_mode 
(mirror/additive) may need to be renamed in a way that changes it from 
describing how the importer is syning to something that defines the type 
of repository.  Like that the repository is intended to be a mirror or 
not.  Perhaps just a "mirror" (bool) attribute.
>
> example
> POST v3/remotes/1234/sync/ repositorty=myrepo_href sync_mode=additive, 
> dl_policy=immediate
> POST v3/remotes/1234/sync/ repositorty=myother_href sync_mode=mirror, 
> dl_policy=deferred
>
>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180312/1b305c87/attachment.htm>