Bug 1286683

Summary: API doesn't support specifying vm-pool type
Product: [oVirt] ovirt-engine Reporter: Michal Skrivanek <michal.skrivanek>
Component: RestAPIAssignee: Michal Skrivanek <michal.skrivanek>
Status: CLOSED NEXTRELEASE QA Contact: Gonza <grafuls>
Severity: medium Docs Contact:
Priority: medium    
Version: ---CC: bugs, ecohen, gklein, khajna, lsurette, mgoldboi, michal.skrivanek, nicolas, rbalakri, sbonazzo, slitmano, smelamud, yeylon, ylavi
Target Milestone: ovirt-3.5.7Flags: michal.skrivanek: ovirt-3.5.z?
michal.skrivanek: planning_ack?
michal.skrivanek: devel_ack+
pnovotny: testing_ack+
Target Release: 3.5.7   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: virt
Fixed In Version: Doc Type: Enhancement
Doc Text:
REST API now supports specifying the pool type on creation (manual or automatic)
Story Points: ---
Clone Of: 1244841 Environment:
Last Closed: 2015-12-21 13:08:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1244841    
Bug Blocks: 1273930, 1275984, 1275987    

Description Michal Skrivanek 2015-11-30 13:46:15 UTC
+++ This bug was initially created as a clone of Bug #1244841 +++

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?

--- Additional comment from Juan Hernández on 2015-07-20 17:12:16 CEST ---

This needs to be implemented in the server, then the SDKs will need to be regenerated.

--- Additional comment from Omer Frenkel on 2015-08-31 08:39:53 CEST ---



--- Additional comment from Sandro Bonazzola on 2015-09-25 15:29:31 CEST ---

Looks like patch is in 3.6 even if bug is not yet acknowledged.
Please move to modified if the patch is included.

--- Additional comment from Yaniv Kaul on 2015-10-19 10:08:48 CEST ---

Sandro - this is a 3.5.6 bug.

--- Additional comment from Sandro Bonazzola on 2015-10-20 14:24:21 CEST ---

(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.

--- Additional comment from Yaniv Kaul on 2015-10-20 15:43:48 CEST ---

(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.

--- Additional comment from Karolína Hajná on 2015-10-22 09:00:25 CEST ---

Verified on ovirt 3.6.0.1-1

--- Additional comment from Eyal Edri on 2015-11-01 15:26:31 CET ---

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)

--- Additional comment from  on 2015-11-04 13:30:43 CET ---

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

--- Additional comment from Michal Skrivanek on 2015-11-23 14:36:13 CET ---

(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

--- Additional comment from Michal Skrivanek on 2015-11-23 14:37:50 CET ---

(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:)

--- Additional comment from Michal Skrivanek on 2015-11-30 14:41:38 CET ---

cloning to 3.5.z

--- Additional comment from Red Hat Bugzilla Rules Engine on 2015-11-30 14:41:42 CET ---

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.

--- Additional comment from Red Hat Bugzilla Rules Engine on 2015-11-30 14:41:42 CET ---

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.

--- Additional comment from Red Hat Bugzilla Rules Engine on 2015-11-30 14:41:42 CET ---

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.

--- Additional comment from Red Hat Bugzilla Rules Engine on 2015-11-30 14:42:43 CET ---

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.

--- Additional comment from Red Hat Bugzilla Rules Engine on 2015-11-30 14:42:43 CET ---

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.

--- Additional comment from Red Hat Bugzilla Rules Engine on 2015-11-30 14:42:43 CET ---

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.

--- Additional comment from Red Hat Bugzilla Rules Engine on 2015-11-30 14:43:38 CET ---

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.

Comment 1 Michal Skrivanek 2015-11-30 13:47:39 UTC
note this is already in 3.5.6 code base. Setting 3.5.7 based on the build meeting request

Comment 2 Gonza 2015-12-17 10:58:05 UTC
Verified with:
ovirt-engine-3.6.2-0.0.master.20151209173828.git652be7e.el6.noarch

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<vmpool href="/api/vmpools/9945c511-8c80-4f94-aaa5-bcd275cbc2f2" id="9945c511-8c80-4f94-aaa5-bcd275cbc2f2">
    <actions>
        <link href="/api/vmpools/9945c511-8c80-4f94-aaa5-bcd275cbc2f2/allocatevm" rel="allocatevm"/>
    </actions>
    <name>test</name>
    <description></description>
    <link href="/api/vmpools/9945c511-8c80-4f94-aaa5-bcd275cbc2f2/permissions" rel="permissions"/>
    <size>3</size>
    <cluster href="/api/clusters/803b4bcf-a03b-4641-be39-297c968bd992" id="803b4bcf-a03b-4641-be39-297c968bd992"/>
    <template href="/api/templates/87786685-3765-46cb-aadc-8a22029b0989" id="87786685-3765-46cb-aadc-8a22029b0989"/>
    <vm href="/api/vms/4383cfae-f6e8-465e-8709-df30778bd8a8" id="4383cfae-f6e8-465e-8709-df30778bd8a8">
        <name>test-1</name>
        <type>server</type>
        <status>
            <state>down</state>
        </status>
        <memory>4294967296</memory>
        <cpu>
            <topology sockets="1" cores="2"/>
            <architecture>X86_64</architecture>
        </cpu>
        <cpu_shares>0</cpu_shares>
        <bios>
            <boot_menu>
                <enabled>false</enabled>
            </boot_menu>
        </bios>
        <os type="other_linux">
            <boot dev="cdrom"/>
            <boot dev="hd"/>
        </os>
        <creation_time>2015-12-17T11:55:44.441+01:00</creation_time>
        <origin>ovirt</origin>
        <stateless>false</stateless>
        <delete_protected>false</delete_protected>
        <high_availability>
            <enabled>false</enabled>
            <priority>0</priority>
        </high_availability>
        <display>
            <type>vnc</type>
            <monitors>1</monitors>
            <single_qxl_pci>false</single_qxl_pci>
            <allow_override>false</allow_override>
            <smartcard_enabled>false</smartcard_enabled>
            <file_transfer_enabled>true</file_transfer_enabled>
            <copy_paste_enabled>true</copy_paste_enabled>
            <disconnect_action>LOCK_SCREEN</disconnect_action>
        </display>
        <sso>
            <methods>
                <method id="GUEST_AGENT"/>
            </methods>
        </sso>
        <timezone>Etc/GMT</timezone>
        <usb>
            <enabled>false</enabled>
        </usb>
        <migration_downtime>-1</migration_downtime>
        <start_paused>false</start_paused>
        <migration>
            <auto_converge>inherit</auto_converge>
            <compressed>inherit</compressed>
        </migration>
        <io>
            <threads>0</threads>
        </io>
        <time_zone>
            <name>Etc/GMT</name>
        </time_zone>
        <large_icon id="e6cdc984-c957-4c99-bdd7-dade4774c14d"/>
        <memory_policy>
            <guaranteed>4294967296</guaranteed>
        </memory_policy>
        <stop_time>2015-12-17T11:55:58.994+01:00</stop_time>
        <initialization>
            <regenerate_ssh_keys>false</regenerate_ssh_keys>
            <nic_configurations/>
        </initialization>
        <placement_policy/>
        <next_run_configuration_exists>false</next_run_configuration_exists>
        <numa_tune_mode>interleave</numa_tune_mode>
    </vm>
    <prestarted_vms>2</prestarted_vms>
    <max_user_vms>1</max_user_vms>
    <type>manual</type>
    <use_latest_template_version>false</use_latest_template_version>
</vmpool>

Comment 3 Michal Skrivanek 2015-12-21 13:08:13 UTC
ovirt 3.5 is no longer built, so closing this as working in the next release 3.6