Fair comment. My concern was the case where a company wants to filter the same content across many repos. Would hate for the user to have to recreate the same filter many times.
-Todd Sent from my iPhone On Dec 23, 2010, at 1:36 PM, Mike McCune <[email protected]> wrote: > On 12/21/2010 01:21 PM, Todd B Sanders wrote: >> Took a few moments to write-up a feature that we'll get added to a >> upcoming sprint. >> >> https://fedorahosted.org/pulp/wiki/CloningFilters >> >> Feedback welcome. >> > > so filters will exist as a top level object that can be managed outside the > scope of individual repos? > > I'm not sure their usage warrants a top level option. Could we just merge it > into the 'pulp-admin repo clone' feature like: > > $ sudo pulp-admin repo clone --help > > Usage: pulp-admin <options> repo clone <options> > > Options: > -h, --help show this help message and exit > --id=ID repository id (required) > --clone_id=CLONE_ID id of cloned repo > --clone_name=CLONE_NAME > common repository name for cloned repo > --feed=FEED feed of cloned_repo: parent/origin/none > --filtertype=TYPE filter type (valid values: WHITELIST, BLACKLIST) > (required) > --filterpackage=NEVRA package name or full nvrea > --relativepath=RELATIVEPATH > relative path where the repository is stored and > exposed to clients; this defaults to repo id > --groupid=GROUPID a group to which the repository belongs; this is just > a string identifier > --timeout=TIMEOUT repository clone timeout > -F, --foreground clone repository in the foreground > > just a thought .. didn't think it needed to be its own top level object in > the CLI and API managed outside the scope of the repos. > > Mike > -- > Mike McCune > mmccune AT redhat.com > Red Hat Engineering | Portland, OR > Systems Management | 650.254.4248 _______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
