Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
errata is associated with only one channel #4
Hi @stevemeier and first of all thanks for you very useful script!
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 (
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?
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.
added a commit
Mar 5, 2018
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.
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.
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)
i have the same problem since i updates spacewalk from 2.6 to 2.7. I get the folowing error:
then on the console:
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.