Re: [katello-devel] Content view filter logic

[Bryan Kearney <bkearney redhat com>]

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