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.
>
> Thanks,
> Johannes
Thank you,
--
Tomas Lestach
RHN Satellite Engineering, Red Hat
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
