Bug 1286683 - API doesn't support specifying vm-pool type
API doesn't support specifying vm-pool type
Status: CLOSED NEXTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: RestAPI (Show other bugs)
---
Unspecified Unspecified
medium Severity medium (vote)
: ovirt-3.5.7
: 3.5.7
Assigned To: Michal Skrivanek
Gonza
virt
:
Depends On: 1244841
Blocks: 1273930 1275984 1275987
  Show dependency treegraph
 
Reported: 2015-11-30 08:46 EST by Michal Skrivanek
Modified: 2016-02-10 14:23 EST (History)
14 users (show)

See Also:
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 08:08:13 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
michal.skrivanek: ovirt‑3.5.z?
michal.skrivanek: planning_ack?
michal.skrivanek: devel_ack+
pnovotny: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 43991 None None None Never
oVirt gerrit 46299 None None None Never
oVirt gerrit 46304 None None None Never

  None (edit)
Description Michal Skrivanek 2015-11-30 08:46:15 EST
+++ 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 08:47:39 EST
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 05:58:05 EST
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 08:08:13 EST
ovirt 3.5 is no longer built, so closing this as working in the next release 3.6

Note You need to log in before you can comment on or make changes to this bug.