I was one of the voices of dissent on this but I am more of a -0/+0 than a -1.
David On Fri, Mar 23, 2018 at 2:56 PM, Dana Walker <dawal...@redhat.com> wrote: > FWIW, I've looked them over and think they're good, but given the +/- 1's > discussion on IRC, you may want to get further grooming consensus still. > > --Dana > > Dana Walker > > Associate Software Engineer > > Red Hat > > <https://www.redhat.com> > <https://red.ht/sig> > > On Fri, Mar 23, 2018 at 1:51 PM, Austin Macdonald <amacd...@redhat.com> > wrote: > >> 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 >> >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev