[Pulp-dev] Importer Name

[Jeff Ortel]

On 03/12/2018 10:28 AM, Jeff Ortel wrote:
> 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.

I have reconsidered this.  Disregard.

>>
>> 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/0859748f/attachment.htm>