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
Sorry, I now found out I was experiencing this bug and was missing the patch:
https://bugzilla.redhat.com/show_bug.cgi?id=707658
So the cloned patches now show up correctly on the UI, but anyways I think
there is some code in here that does strange things. E.g. when I analyze the
file PublishErrataAction.java:
The newly cloned patch is published by calling in line 80:
ErrataManager.publishErrataToChannelAsync(...)
This also triggers insertion into the cache table ("rhnServerNeededCache").
So why do we need to call later on (and without the actual errata ids):
ErrataCacheManager.insertCacheForChannelPackagesAsync(chanList, pidList); (line
100)
This seems to insert another row into rhnServerNeededCache where the eid is
null!
If this is wanted behaviour, then what is it for?
Thanks,
Johannes
--
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
