Description of problem: When deploying a VmPool using the Python-SDK interface, the Quota is replaced by the first available one in the list of Quotas instead of using the one's that set in the template. pool = params.VmPool(name='TEST', cluster=api.clusters.get(name='Whatever'), template=api.templates.get(id='f377eb7f-885c-4443-9b0c-bf6ba8e34c21'), max_user_vms=1, size=1, type_='manual') api.vmpools.add(pool) Template with the specified ID has a quota called 'X', when deploying the pool the quota is overridden by the first available in the list of quotas instead of 'X'. Version-Release number of selected component (if applicable): 3.6.7.0 How reproducible: Always
I believe that the SDK isn't the source of this problem. However, to verify that I would need to see what is the request sent by the SDK when you run that script. Can you add the "debug=True" parameter to the constructor of the API object, run the script and share the ouptut? Note that the output will contain the HTTP "Authorization" header, including your user name and password. Make sure to remove it before sharing. In addition I'd suggest to avoid setting the "cluster" and "template" parameters to the objects obtained from "api.clusters.get" and "api.templates.get", as then you will be sending to the server the complete representation of these objects, when you only need the id/name. Try to do the following instead: cluster = api.clusters.get(name='...') template = api.templates.gete(name='...') pool = params.VmPool( name='TEST', cluster=params.Cluster(id=cluster.get_id()), template=params.Template(id=template.get_id()), ... )
Created attachment 1205289 [details] Debug log of the vmpool.add() call Log attached.
Thanks, that confirms that the SDK isn't the cause of the problem, as it is sending the expected request. I'am moving the bug to the backend component and to the SLA team for further investigation.
Just to clarify (FWIW): Our oVirt engine version is 4.0.3, but due to compatibility reasons regarding an app, our Python-SDK version is 3.6.7.
Currently, REST api ignores template's quota.
Hi Verified with rhevm-4.0.5.4-0.1.el7ev.noarch according the following flow: 1. Create 3 qoutas in DC - a,b,z 2. Set the qouta mode in DC to audit* 3. Edit a template in the DC and set qouta to 'z' 4. Create a vm pool from the template via API (I wasn't sure if at the end it has something to do with API or not). Result: The vm pool and all vms in it are set t qouta 'z' as expected. * Is this the correct flow? What was the qouta mode on the DC when the template was created? and when the vm pool was created?
The VMpools don't have to be created via the API, the problem just happens when *moving* the disk of a VM that is part of a VMpool via the API. In any moment the quota mode has been 'audit': Both at template creation time and the VM creation time. Otherwise the flow is correct.
Argh, sorry, disregard the first line in the last comment, I mixed up two BZ. The correct sentence is: As per my tests, yes, the VMpool is created via the Python SDK (thus using the API). That is when it doesn't honor the Quota. When the VMpool is created via the webadmin the Quota is respected.