Description of problem: When processing a submitted job, TaskPackage.lazy_create can trigger a flush while the job is not fully populated, resulting in a NULLable violation. Version-Release number of selected component (if applicable): 0.9 How reproducible: always Steps to Reproduce: 1. Submit a job containing a <package/> whose name has never been used in Beaker before Actual results: Failed to import job because of: (OperationalError) (1048, "Column 'job_id' cannot be null") 'INSERT INTO recipe_set (job_id, priority, queue_time, result, status, lab_controller_id, ttasks, ptasks, wtasks, ftasks, ktasks) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s)' (None, 'Normal', datetime.datetime(2012, 10, 24, 0, 29, 37, 807458), 'New', 'New', None, 0, 0, 0, 0, 0) Expected results: Job is accepted, task_package row is created. Additional info: Reported by Jaroslav Kortus: https://lists.fedorahosted.org/pipermail/beaker-devel/2012-October/000379.html
Workaround is to manually insert the offending task_package row: INSERT INTO task_package (package) VALUES ('new-package-name');
Actually I think this affects any job which includes any <package/> element, which makes this quite a serious regression... still investigating.
This was a regression in 0.8.2 and affects any job containing a <package/> element. Like all the other lazy_create bugs we have had, it is due to this change introducing nested transactions: http://git.beaker-project.org/cgit/beaker/diff/Server/bkr/server/model.py?id=bb12ed97 The workaround in comment 1 is not valid either. The only workaround is to avoid using <package/>. One possibility is to use a <ks_append/> containing a second %packages section, although I think this breaks in very old Anaconda versions. Another option is to pass ks_meta="packages=onepackage:anotherpackage" inside <recipe/>.
On Gerrit: http://gerrit.beaker-project.org/1436
Verified to be fixed. Ran the test case against the release-0.10 branch and against the master branch. It fails in the latter. Also submitted a simple Job with additional <package> specification. The kickstart file was generated correctly.
This has now been released
This bug still exists. My fix only works in the case with one recipeset and one recipe and no guestrecipes. I also just discovered the reason why nobody has hit this bug in our production Beaker instance. There is one very small but very important difference in the production schema vs our source code (and tests): recipe.recipe_set_id and recipe_set.job_id are NULLable in production. That will also need to be fixed: bug 881563.
On Gerrit: http://gerrit.beaker-project.org/1525
Beaker 0.11.0 has been released.