-
Notifications
You must be signed in to change notification settings - Fork 70
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
Provisioning Beaker machines w/count > 1 causes XML RPC errors #1693
Comments
@Dannyb48 |
This should fix CentOS-PaaS-SIG#1693 where two resources belong to the same job are filtered to avoid xmlrpc condition
This should fix CentOS-PaaS-SIG#1693 where two resources belong to the same job are filtered to avoid xmlrpc condition
I agree I think this is an unknown change on Beaker server side. Yes, I am using latest develop branch. Good catch, it looks like it's not reproduceable on python 3. Although, I have identified and tested a fix for py2. I just got done testing it with python3 and it worked fine. The fix will allow whatever changes happened on the Beaker server side to be backwards compatible for python 2 as well. I just submitted it. I'll let you guys review to see if you want to merge it in. |
This should fix CentOS-PaaS-SIG#1693 where two resources belong to the same job are filtered to avoid xmlrpc condition
Describe the bug
On March 11th carbon was provisoining beaker systems with a count of 2 and everything was working creating and destroying fine. From that point on provisioning were failing on destroy. The error from Beaker is the following.
xmlrpclib.Fault: <Fault 1: "<class 'sqlalchemy.exc.OperationalError'>:(OperationalError) (1213, 'Deadlock found when trying to get lock; try restarting transaction') 'INSERT INTO job_activity (id, job_id) VALUES (%s, %s)' (92678998L, 4138086L)
But the issue seems to be cosmetic in the sense that when I lookup the beaker job id the job was indeed cancelled. So it seems like some type of race condition.
I was able to reproduce this outside of Carbon with the following PinFile and a count of greater than 1. If I use the same PinFile and specify just a count of 1 there are no issues on:
STACKTRACE
To Reproduce
Steps to reproduce the behavior:
linchpin -vvvv up
linchpin -vvvv destroy
The text was updated successfully, but these errors were encountered: