[Pulp-dev] Importer Name

[Justin Sherrill]

On 03/08/2018 11: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.
I'm fairly apathetic to a name change.  It would be annoying to us in 
katello land, but not really a huge deal either way.  I don't think 
importer a bad name, as it does hold configuration around 'importing'.  
the fact that it itself doesn't actually do the importing is a technical 
detail and really isn't a big deal IMO. User's likely wouldn't care, but 
for developers i guess its just weighing a more 'perfect' name to the 
work of changing everything (including documentation) at this stage.

>
> -------------------------------------------------------
> 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.
>
> 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

So as a user using some future cli, i have to magically 'remember' these 
values?  If so, that seems like a bad user experience and kinda defeats 
the purpose of pulp holding configuration.  Could it be stored on the 
repository itself (or somewhere else) if it doesn't make sense to store 
on the importer/remote?

If you're serious about this, this would be something to ask current 
users of pulp as it seems kind of a big deal.
>
>
>
> _______________________________________________
> 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/7fafa4c2/attachment.htm>