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