[Pulp-dev] Importer Name

Fri Mar 23 20:42:32 UTC 2018

Austin, those look good to me also. I've marked them as groomed and added
them to the sprint.

On Fri, Mar 23, 2018 at 2:56 PM, Dana Walker <dawalker at redhat.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/4900c0ea/attachment.htm>