Would anyone mind grooming these? Also, last change to shut it down :) https://pulp.plan.io/issues/3488 https://pulp.plan.io/issues/3492
On Fri, Mar 16, 2018 at 9:27 AM, Austin Macdonald <amacd...@redhat.com> wrote: > 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 <davidda...@redhat.com> > 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 <jor...@redhat.com> 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 <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 >>>> listPulp-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev