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 <jor...@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 > listPulpemail@example.com://www.redhat.com/mailman/listinfo/pulp-dev > > > > > _______________________________________________ > Pulp-dev mailing list > Pulpfirstname.lastname@example.org > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list Pulpemail@example.com https://www.redhat.com/mailman/listinfo/pulp-dev