[Pulp-dev] Importer Name

[David Davis]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180313/fc013eef/attachment.htm>