[katello-devel] Content view filter logic

[Bryan Kearney]

On 10/24/2012 04:29 PM, Justin Sherrill wrote:
> On 10/24/2012 04:04 PM, Bryan Kearney wrote:
>> On 10/24/2012 03:51 PM, David Davis wrote:
>>> Here are my notes from today's meeting. Please review them and let me
>>> know what you all think and then I'll add them to the content view
>>> page on the wiki.
>>>
>>> 1. a. If there is no include filter (aka whitelist filter),
>>> everything is included.
>>>     b. If there are no include filters and only exclude filters (aka
>>> blacklist filters), those exclude filters then run on all
>>> packages/errata.
>>>
>>> 2. If there is an include filter (aka whitelist) then only the
>>> packages/errata included will get included. Everything else is thus
>>> excluded.
>>>
>>> 3. If there are include and exclude filters, the exclude filters take
>>> presidence. That is to say the include filters get processed first,
>>> then the exclude filter excludes content from the set included by the
>>> include filters.
>>>
>>> Thanks!
>>>
>>
>> Some other questions:
>>
>> 1) What does deleting a definition do to the views which have been
>> promoted.
>          I don't think anything happens to the views.  They stay where
> they are.
>
>> 2) The refreshing a view concept is not 100 clear to me. Perhaps We
>> can push off doing refresh now, or ceate "refresh only" content views.
>       The idea is to regenerate all of the repositories.  So we would
> probably wipe them all and recreate them (if thats easiest).    We could
> push off doing refreshing, but as eric mentions that leaves around a lot
> of cruft.
>
> If a common workflow is:
>
> 1.  Generate a new view
> 2.  Promote new view to next environmnet
> 3.  Migrate all systems from old view to new view
> 4.  Delete old view in next environment
> 5.  repeat for all environments
>
> You're introducing 2 additional steps for each environment.  I think
> this will be more common that wanting to leave dozens of old views around.
>
> If we do push off refreshing, we need to make it VERY easy to move large
> numbers of systems around.  We still need to make it easy regardless,
> but its much more important if you can't refresh the views.

So,can we dothis at promotion then? Make part of the change set:

promote this view, and move all system from that view to this view? That 
way, you make promotion decisions in one place, and content veiew 
definitions in another.

>
>> 3) For me, the relationship between errata and packages is not clear.
>> if the filter excludes httpd, and includes all errata then what
>> happens when an errata comes in with httpd? If I include only httpd,
>> and include all errata what happens?
> So as I said, some discussion and brainstorming needs to be done around
> this.  We intentionally didn't get into these details when we planned
> out this feature months ago just due to the detailed complexity.  But
> for this case to me, if i exclude 'httpd' that should exclude any errata
> that only includes 'httpd', even if i have included it in my time
> frame.  Goes back to the exclude filters take precedence.   I would
> probably argue that we should only have 'package' excludes, no 'errata'
> or 'package group' excludes.

Dunno.. need to think on this a bit.


>
>
>> 4) Justin says he has a solution, but I would like to understand how I
>> would apply Errata X and Errata Y (both of which are RHEL 6.3 errata)
>> onto the RHEL 6.2 content steam. Currently, 6.2 and 6.3 are unique
>> repositories in a single product.
> 1.  Create a content view definition
> 2.  Add "Red hat enterprise linux product" with only "6Server" repo
> selected.  6Server will have all updates up until today.
> 3.  Add a filter for the 6Server repo  only including Errata up to 6.2's
> release date.
> 4.  Add an additional filter that satisfies this user story:
>
>   * As a user with administer privileges on Content View Definitions or
>     modify privilege on a Content View Definition, I should be able to
>     define an errata filter to whitelist errata by IDs.

Will folks know this date? I can see how this will work, but it seems 
cumbersome. It is probably good enough for v2.0

>
> For Errata X & Errata Y.  I'm not sure that this was shown in the
> mockups, but it needs to be added if its not there.

I did not see it, I only saw date range.

>
> 5.  Publish view, promote, and subscribe a system.
>
>
> -Justin
>
>
>>
>> -- bk
>>
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
>
>
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
>