In pulp3, users need to keep track for a number of things. For example,
without auto publish, users need to keep track of which importer(s) and
publishers need to be used for sync/publish workflows. I fully expect
that users using the API will be maintaining some kind of
automation/orchestration on their end (shell scripts, ansible). So,
keeping track of sync and download policies does not seem like much of a
burden. Also, after further consideration, I don't think that storing
either the sync (mode) or download policy on the repository is appropriate.
On 03/13/2018 04:59 PM, David Davis wrote:
Can you elaborate on what made you reconsider? Asking because I still
see the point that you and Justin raised about dropping the fields as
an issue.
David
On Mon, Mar 12, 2018 at 12:31 PM, Jeff Ortel <[email protected]
<mailto:[email protected]>> wrote:
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] <mailto:[email protected]>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
[email protected] <mailto:[email protected]>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-dev
