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
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-dev
_______________________________________________
Pulp-dev mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-dev
