[katello-devel] Content view filter logic
Kyle Baker
kybaker at redhat.com
Thu Oct 25 20:28:22 UTC 2012
Kyle Baker
---
UX Team
Desk 978 392 3116
IRC kylebaker
----- Original Message -----
> 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.
[Kyle] Can we give the user the choice to specify errata which are included, excluded, date/type, or for a specific product. When a user chooses a specific product it could pre-populate a whitelist of the errata pushed for that product.
>
> -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.
[Kyle] In the wireframes the user can specify errata which are included, excluded, by date. I only showed the detail view for date and type.
> >
> >>
> >> 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
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
>
More information about the katello-devel
mailing list