On 03/05/2012 03:40 PM, Tomas Lestach wrote:
> On Friday 02 of March 2012 18:11:41 Johannes Renner wrote:
>> 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=3707af41
>>> 49d84a1ddb1ce693c78f7b791a044cd1
>>>
>>> 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?
>
> Right Johannes,
>
> good catch.
> this definitelly isn't wanted behavior.
> If the added packages to a channals are associated with any erratum (what is
> our case), we definitelly want to consider also the erratum, when
> regenerating
> errata cache.
>
> Will you find some time to verify the behavior, when removing the errata
> cache
> update on line 100?
> If not, please, file a BZ for the issue.
I will find time for that in the next days and I can then come up with a new
patch for that file after I verified the behavior.
Regards,
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
