[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