-
-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
errata is associated with only one channel #4
Comments
I just ran an import on a fresh install of Spacewalk 2.7 with only the Updates channels synced for CentOS 6 and 7. This is the result I got:
This looks fine. The only difference I see in your import is that you were updating an errata (possibly because of newly imported packages after a sync). This should not behave differently, but I will give it a try. |
OK, I think I have found the issue. When the errata-import script detects that an errata already exists but finds new packages that belong to it (e.g. after a sync), it adds them using the addPackages API call. The missing step after this seems to be a "re-publish", which is not initiated by addPackages. This should be a fairly straight-forward addition to errata-import.pl. |
I couldn't go to sleep with this bug still open. |
Wow! I didn't expect a so fast reply and solution, @stevemeier ! I feel guilty for you lost sleep :) Before the patch
After the patch:
As you can see, after the patch the script takes nearly 20 hours (!) to complete the execution. A minor glitch: the counter "errata updated" doesn't seem to work. |
The re-publishing should now be fixed. |
Great! I'm trying the new version now. I'll let you know as soon as it finish ;) |
Sorry for the waiting, @stevemeier. I re-tested the script with the last patch and now it's fast again but in my last run there wasn't any new errata to create or something to update.
I also want to test the script in case of an update to an errata.
Here is the full strack-trace found in
Strangely enough, the errata is successfully updated even if the script ends with an error. |
The documentation of the Spacewalk API is, unfortunately, not great. When the republishing is done in line 656, the scripts attempts to publish the errata to all channels that contain an affected RPM. This includes the channel(s) it has previously been published too. To fix this, I would have to make the code a lot smarter. I will see if that's possible. |
Thanks for taking care of this, @stevemeier! |
Hi @stevemeier just to help you troubleshoot and analyse the issue, I'll paste here a snippet of the stack error that the errata-import.pl produces:
P.s.: associating by hand the relevant channel to the errata from the webgui and re-launching the script fixed the issue (I did this task for every errata that was breaking the script) |
Hi, i have the same problem since i updates spacewalk from 2.6 to 2.7. I get the folowing error: then on the console:
|
@cheeseburger12: Can you please post the full stack trace? I don't really get any info from the piece you posted. |
@angystardust, @cheeseburger12 |
Thank you a lot @stevemeier. I'll test during the next weeks and let you know ;) |
I've all times the problem that the "errata-import" script stops with: I also clear the hole erratas with spacecmd(spacecmd -y "errata_delete *") and your wipe script. After that i see the issue again. In the frontend I could not see any more "erratas", but in the database. That's why I deleted the remaining "erratas" directly from the database: now it seems to work and i will test it to other channel. Thank you steve |
@cheeseburger12 Your issue sounds like a database inconsistency. My scripts asks the API for a list of existing Errata before trying to create them. So in your case the API did not report this Errata as existing but then complained when the script tried to create it. Unfortunately, such a thing is almost impossible to reproduce. |
Absolutely right. Thank you very much. I assumed that it is on the second channel |
Hi @stevemeier and first of all thanks for you very useful script!
Yesterday I noticed a very strange problem on my Spacewalk 2.7 setup with both Centos6 and CentOS-7 channels synced.
Let's take for example
CESA-2018-0093
. This is the relevant entry in the errata.latest.xml:If I run your script with the following parameters:
at the end of the script execution, I can successfully see the errata published on my Spacewalk instance but it's only linked with one channel (
centos7-x86_64
) instead of bothcentos6-x86_64
andcentos7-x86_64-updates
channelsYou can see from the output of
spacecmd
that the affected packages are both linked to the errata but the linked channel is only one:This is the what the script logs if I put it in debug mode:
Is it the expected behaviour? Is there a way to link both channels to I can see the relevant errata applicable for all the relevant systems?
Thanks a lot for your help
The text was updated successfully, but these errors were encountered: