On Fri, Mar 9, 2018 at 3:28 PM, Brian Bouterse <bbout...@redhat.com> wrote:
> I left some responses inline.
> On Thu, Mar 8, 2018 at 11:13 AM, Austin Macdonald <aus...@redhat.com>
>> 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.
> I'm +0 thinking that either name is fine but that those unfamiliar with
> git, but those familiar with git would benefit from the name change.
>> 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
>> Sync settings
>> 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
>> POST v3/remotes/1234/sync/ repositorty=myrepo_href sync_mode=additive,
>> POST v3/remotes/1234/sync/ repositorty=myother_href sync_mode=mirror,
> +1 to this change. I think this makes sense to specify the sync_mode and
> dl_policy with sync params with each download because the Importer having
> one policy apply to any repo that uses it does not make much sense.
>> Pulp-dev mailing list
> Pulp-dev mailing list
Pulp-dev mailing list