[Pulp-list] Filters

[Todd Sanders]

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 <mmccune at redhat.com> 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