[katello-devel] Content view filter logic

[Bryan Kearney]

On 10/25/2012 09:30 AM, Justin Sherrill wrote:
> On 10/24/2012 04: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.
>>
>>>
>>>> 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
>
> So for satellite customers they seemed smart enough to find this
> information.  But it really gets down to when you say "6.2" what does
> that mean?   Generally customers mean the package set when 6.2 is
> released.  The "Rhel 6.2" repo does not give them this does it?  From my
> understanding the 6.2 repo contains all package up to the release of
> RHEl 6.3.  I'm not sure that this is really what customers want anyways.

True.. it is closer but may not be exact. Per the earlier discussions, I 
think I am fine with this for 2.0. I think it gets us to maintenance 
windows which is a huge step forward.

-- bk