[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spacewalk-devel
Subject:    Re: [Spacewalk-devel] [PATCH] Bug about cloned channels and errata
From:       Johannes Renner <jrenner () suse ! de>
Date:       2012-02-29 16:52:49
Message-ID: 4F4E57E1.1060400 () suse ! de
[Download RAW message or body]

On 02/29/2012 05:38 PM, Cliff Perry wrote:
> On 02/29/2012 11:05 AM, Johannes Renner wrote:
> > Hello,
> > 
> > I am investigating into a bug about cloned channels and errata. This is how to
> > reproduce it on the UI:
> > 
> > 1. Clone a channel that contains errata, but select "clone without errata"
> > 2. Go to Channels -> Manage Software Channels -> Errata -> Add -> Add Custom \
> > Errata (or Add RedHat Errata) -> Unmark the checkbox "Package Assoc." if \
> > necessary 3. Choose an Erratum, clone it and confirm
> > 
> > Result: The cloned erratum can be found in the cloned channel as "CLxxx"
> > 
> > 5. Now subscribe a system to the newly cloned channel only
> > 6. Go to this System -> Software -> Errata
> > 
> > Result: There is two errata listed, "xxx" and "CLxxx", but only "CLxxx" should \
> > be. Also the table 'RhnServerNeededCache' shows even more entries where errata_id \
> > == null? 
> > I found a lot of open bugs about this topic, but not exactly this one. If one of \
> > you can reproduce it I could create a bug report for spacewalk, or are you aware \
> > of such misbehavior already?
> > 
> > To me it looks like the used statement ('insert_new_cache_entries_by_packages' in
> > ErrataCache_queries.xml) is not doing the right thing. There even seems to be an
> > easy fix that I attached as a patch for master, which just calls a stored \
> > procedure ('update_needed_cache_for_channel', ErrataCache_queries.xml) instead.
> > 
> > Maybe someone of you who knows about this code could have a look at the issue,
> > I might be missing something ..
> > 
> 
> Replying to add more background. I was not aware of this specific bug
> myself either. I'd be interested to see if we can reproduce on Sat 5.4
> code as well as current Spacewalk code.
> 
> This area of the code seems to get updates and re-factor once every
> couple of years, due to subtle bugs in logic, along with
> scalability/performance feedback.
> 
> The particular line you attached to propose changing was last changed in
> Feb 2009 as part of a larger re-factor:
> http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=3707af4149d84a1ddb1ce693c78f7b791a044cd1
>  
> If memory serves me correct, we were in the middle of a Satellite
> release cycle, so changing the stored procedure was not an ideal
> solution for Satellite. We fixed Java code - which performed well.
> 
> I'm not sure if I'd want the fix, as proposed, in 1.7, without us
> spending time to confirm it is the best solution for logic and
> performance. I don't think we will have time to dedicate to assist until
> post 1.7. If one the guys finds we have time to dig in before 1.7 goes
> out in the next week (hopefully) - we will.
> 
> Cliff

Thanks for your reply. The patch was not intended to go into 1.7 directly and it is
probably not even complete as it is. It rather reflects the smallest possible change
that seems to fix the bug. More code in the same class will be obsolete when we call
the stored procedure, e.g. we do not need the list of all packages of the current
channel anymore.

If one of you could have a look as soon as there is time, it would be great.
After 1.7 is fine of course.

Thanks,
Johannes

-- 
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer


[prev in list] [next in list] [prev in thread] [next in thread]