Description of problem:
This is fresh install of 3.3.1 beta engine running on CentOS 6.4. Trying to create VM from Foreman 1.2/1.3 fails and shows following error message in engine.log "ERROR: insert or update on table "images" violates foreign key constraint "fk_images_quota". Full log attached.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create new VM from Foreman
Creating of VM fails and Foreman displays error:
Unable to save
Failed to create a compute dev-el6 (oVirt) instance gg6.domain.tld
VM is created successfully into oVirt.
Created attachment 814461 [details]
engine.log during VM create
The following upgrade script
03_03_0900_quota_id_foreign_key.sql added this FK constraint :
ALTER TABLE images ADD CONSTRAINT fk_images_quota FOREIGN KEY (quota_id) REFERENCES quota(id) ON DELETE SET NULL;
So, it seems that there is an attempt to create a VM with an invalid QUOTA ID
Some additional information about my setup if needed:
Quota is disabled on this datacenter and Foreman is using admin@internal to
I tried enabling quota and problem still exists. Also it seems that it's not possible to set quota for admin.
Can you see if you have quota definition in foreman compute resource definition?
(In reply to Gilad Chaplik from comment #4)
> Can you see if you have quota definition in foreman compute resource
It shows Quota ID field but there are no variables. Quota is currently disabled in datacenter.
I just tried enabling quota in datacenter and made quota definition for it. It shows in compute resource definition and selecting it it's possible to create VM's from foreman.
So this seems to be problem only if quota is disabled and there is no quota defined in oVirt.
The problem is that foreman is sending empty string for disk's quota (not for vm btw), then the engine subs empty string with empty UUID (000...). prior to the fix mentioned in comment 2, it was possible to save empty UUID as quota id.
do we treat this as a regression to backward compatibility, or a change due to a bug which must be fixed and foreman needs to be changed?
(In reply to Itamar Heim from comment #7)
> do we treat this as a regression to backward compatibility, or a change due
> to a bug which must be fixed and foreman needs to be changed?
I don't think it's a backward compatibility issue, since foreman didn't send a empty UUID, just an empty string and the REST treat it as empty UUID.
Since quota is not supported in the REST, I guess we can simply ignore empty UUID
in the engine, and fix it in foreman ovirt component (sent patches for both).
Samuli (the bug reporter) verified that the problem is solved (by fixing rbovirt).
oVirt 3.3.1 has been released