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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> [email protected]https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
