[Pulp-dev] Importer Name

Fri Mar 23 17:51:44 UTC 2018

Would anyone mind grooming these? Also, last change to shut it down :)
https://pulp.plan.io/issues/3488
https://pulp.plan.io/issues/3492

On Fri, Mar 16, 2018 at 9:27 AM, Austin Macdonald <amacdona at redhat.com>
wrote:

> 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/20180323/a5ecf63f/attachment.htm>