[Pulp-dev] Importer Name

Fri Mar 16 13:27:00 UTC 2018

Ive created tasks to do this work.

Rename:
https://pulp.plan.io/issues/3488

Move sync_mode, remove download_policy
https://pulp.plan.io/issues/3492

Each of these has corresponding plugin tasks, which are related to them.

On Thu, Mar 15, 2018 at 4:16 PM, David Davis <daviddavis at redhat.com> wrote:

> Austin and Jeff,
>
> Thanks for the responses. I am happy with moving forward and opening an
> issue in redmine for this change
>
> I think I am +0 on dropping the fields. However, if we start to get
> complaints from our users, I think we should consider adding them back.
>
>
> David
>
> On Wed, Mar 14, 2018 at 10:16 AM, Jeff Ortel <jortel at redhat.com> wrote:
>
>> 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> 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 listPulp-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180316/ebaddbe4/attachment.htm>