[Pulp-dev] Importer Name
Jeff Ortel
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.
>
>
> David
>
> 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:
>>> 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
>>> Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>> <https://www.redhat.com/mailman/listinfo/pulp-dev>
>>
>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
> https://www.redhat.com/mailman/listinfo/pulp-dev
> <https://www.redhat.com/mailman/listinfo/pulp-dev>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180314/f370f714/attachment.htm>
More information about the Pulp-dev
mailing list