[Pulp-dev] Importer Name

Dana Walker dawalker at redhat.com
Fri Mar 23 18:56:54 UTC 2018


FWIW, I've looked them over and think they're good, but given the +/- 1's
discussion on IRC, you may want to get further grooming consensus still.

--Dana

Dana Walker

Associate Software Engineer

Red Hat

<https://www.redhat.com>
<https://red.ht/sig>

On Fri, Mar 23, 2018 at 1:51 PM, Austin Macdonald <amacdona at redhat.com>
wrote:

> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/250ccf9c/attachment.htm>


More information about the Pulp-dev mailing list