We're deploying a Django app which needs to distinguish between which kind of VmPool should be created: automatic or manual. In our case, we need to assign N VMs from the pool to N users and once assigned, we need those VMs don't return to the pool so the users can use the same VMs all time long. Therefore, we need 'Manual' VmPools. Currently (oVirt 3.5.3.1-1, ovirt-engine-sdk-python 3.5.2.1), the SDK library doesn't seem to support specifying which kind of VmPool should be created, creating an Automatic one by default. Could this parameter be implemented?
This needs to be implemented in the server, then the SDKs will need to be regenerated.
*** Bug 1258245 has been marked as a duplicate of this bug. ***
Looks like patch is in 3.6 even if bug is not yet acknowledged. Please move to modified if the patch is included.
Sandro - this is a 3.5.6 bug.
(In reply to Yaniv Kaul from comment #4) > Sandro - this is a 3.5.6 bug. Yaniv this is a proposed ZStream bug, means it has to be merged in 3.6 and then backported to 3.5. For 3.6 it's on QA being the fix included in last build moved to QE. Missing to be approved and cloned for ZStream.
(In reply to Sandro Bonazzola from comment #5) > (In reply to Yaniv Kaul from comment #4) > > Sandro - this is a 3.5.6 bug. > > Yaniv this is a proposed ZStream bug, means it has to be merged in 3.6 and > then backported to 3.5. > For 3.6 it's on QA being the fix included in last build moved to QE. > Missing to be approved and cloned for ZStream. So it looks to me like the targets are wrong, as they are for 3.5.6: - If this one is for 3.6, then they are wrong. - If it's for 3.5.6, then this should be the cloned bug.
Verified on ovirt 3.6.0.1-1
this bug has both 3.5.z & 3.6.0 flags, in bugzilla lang it means its a clone candidate from 3.6.0 to 3.5.z meaning it's pending a clone and wasn't fixed for 3.5.z. if this isn't the case, please fix flags accordingly, if it is the case, then please clone the bugs to 3.5.7 (3.5.6 was built already)
This bug has status VERIFIED but I can't seem to find it in the oVirt 3.6 bugs fixed list at [1]. Was this included in that version? [1]: http://www.ovirt.org/OVirt_3.6_Release_Notes
(In reply to Eyal Edri from comment #8) > this bug has both 3.5.z & 3.6.0 flags, in bugzilla lang it means its a clone > candidate from 3.6.0 to 3.5.z meaning it's pending a clone and wasn't fixed > for 3.5.z. > > if this isn't the case, please fix flags accordingly, > if it is the case, then please clone the bugs to 3.5.7 (3.5.6 was built > already) missing planning_ack actually it was fixed in 3.5.6 as well, yes, it's a mess
(In reply to nicolas from comment #9) > This bug has status VERIFIED but I can't seem to find it in the oVirt 3.6 > bugs fixed list at [1]. Was this included in that version? > > [1]: http://www.ovirt.org/OVirt_3.6_Release_Notes I confirm the fix is included in 3.6.0 GA despite missing in the list:)
cloning to 3.5.z
This bug is not marked for z-stream, yet the milestone is for a z-stream version, therefore the milestone has been reset. Please set the correct milestone or add the z-stream flag.
Fixed bug tickets must have target milestone set prior to fixing them. Please set the correct milestone and move the bugs back to the previous status after this is corrected.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
According to verification status and target milestone this issue should be fixed in oVirt 3.6.1. Closing current release.
I'm not sure this has been correctly fixed... oVirt 3.6.2.6.1 ovirt-engine-sdk-python 3.6.0.3 This snippet crashes: from ovirtsdk.xml import params from ovirtsdk.api import API kvm = API(url='https://fqdn/api', username='admin@internal', password='***', insecure=True) pool = params.VmPool(name='TEST', cluster=kvm.clusters.get(name='Default'), template=kvm.templates.get(name='ubuntu'), max_user_vms=1, vm_pool_type=None) Error: Traceback (most recent call last): File "test.py", line 6, in <module> pool = params.VmPool(name='TEST', cluster=kvm.clusters.get(name='Default'), template=kvm.templates.get(name='ubuntu-1404'), max_user_vms=1, vm_pool_type=None) TypeError: __init__() got an unexpected keyword argument 'vm_pool_type' Indeed, having a look at the xml/params.py file: class VmPool(BaseResource): ... def __init__(self, actions=None, href=None, id=None, name=None, description=None, comment=None, creation_status=None, link=None, size=None, cluster=None, template=None, vm=None, prestarted_vms=None, max_user_vms=None, display=None, rng_device=None, soundcard_enabled=None, type_=None) Seems that vm_pool_type hasn't been included in the __init__ function. There is a 'type_' which maybe intended to be vm_pool_type?
I confirm that 'type_' does the job for specifying the type of pool (manual, automatic). I wonder if vm_pool_type= was meant to be the parameter to set it or if it references something different?
Please look at comments 21 and 22.
As far as I see in the code and API spec, there is no vm_pool_type property. There is type_ property in VmPool class that specifies the type of the pool. In api.xsd: <xs:complexType name="VmPool"> <xs:complexContent> <xs:extension base="BaseResource"> <xs:sequence> <xs:element name="size" type="xs:int" minOccurs="0"/> <xs:element ref="cluster" minOccurs="0" maxOccurs="1"/> <xs:element ref="template" minOccurs="0" maxOccurs="1"/> <xs:element ref="vm" minOccurs="0" maxOccurs="1"/> <xs:element name="prestarted_vms" type="xs:int" minOccurs="0"/> <xs:element name="max_user_vms" type="xs:int" minOccurs="0"/> <xs:element ref="display" minOccurs="0" maxOccurs="1"/> <xs:element ref="rng_device" minOccurs="0" maxOccurs="1"/> <xs:element ref="soundcard_enabled" minOccurs="0" maxOccurs="1"/> <xs:element name="type" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> If you've seen vm_pool_type somewhere in the documentation, it is incorrect.
Then it must be some kind of autocompletion at IPython - Now looking at the code I see there's a VmPoolTypes class which indeed has this attribute, so maybe it's coming from it. Disregard the comments above then.