[katello-devel] Content view filter logic

[Mike McCune]

On 10/24/2012 01:42 PM, Bryan Kearney wrote:
> 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.
>

we could but if the view is baked into the client as a variable, similar 
to how we do with $ENV it may be hard todo.  Would be easier to keep 
them pointed at the same thing which changes if you need it updated.


>>
>>> 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.
>

eventually you could offer the user a choice of precedence but I think 
our first attempt would go as Justin says:

blacklisting beats whitelisting

we could eventually offer policy where users could construct AND vs OR 
conditions when you stack filters to determine the venn-diagram of what 
is included within the view but I think the first time around we just 
code these conditions in with an eye for future flexibility.


>
>>
>>
>>> 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


X.Y dates are not something we can know yet pragmatically.  Users will 
have to follow announcements to calculate the date.  I'd argue it is 
good enough for a first cut at this feature.


Mike
-- 
Mike McCune
mmccune AT redhat.com
Red Hat Engineering       | Portland, OR
Systems Management        | 650-254-4248