[katello-devel] Content view filter logic

Thu Oct 25 13:30:34 UTC 2012

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.

-Justin

>
>>
>> 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
>>
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel