[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Pulp-dev] Importer Name



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. 

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]