[Pulp-dev] Importer Name
jortel at redhat.com
Wed Mar 14 14:16:18 UTC 2018
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.
> On Mon, Mar 12, 2018 at 12:31 PM, Jeff Ortel <jortel at redhat.com
> <mailto:jortel at redhat.com>> wrote:
> On 03/12/2018 10:28 AM, Jeff Ortel wrote:
>> On 03/08/2018 10:13 AM, Austin Macdonald wrote:
>>> 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
>>> Sync settings
>>> 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)
> I have reconsidered this. Disregard.
>>> 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 <mailto:Pulp-dev at redhat.com>
> Pulp-dev mailing list
> Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev