Bug 1160846

Summary:	Can't add disk to VM without specifying disk profile when the storage domain has more than one disk profile
Product:	[Retired] oVirt	Reporter:	Juan Hernández <juan.hernandez>
Component:	ovirt-engine-core	Assignee:	Doron Fediuck <dfediuck>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Jiri Belka <jbelka>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	3.5	CC:	amureini, bugs, daniel.helgenberger, dfediuck, ecohen, iheim, jbelka, juan.hernandez, lsurette, rbalakri, rgolan, sbonazzo, s.kieske, usurse, yeylon
Target Milestone:	---	Keywords:	Regression, Reopened
Target Release:	3.5.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	sla
Fixed In Version:	ovirt-3.5.1_rc1	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-09-04 12:47:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	SLA	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1155170, 1193058, 1196662, 1197441, 1209505

Description Juan Hernández 2014-11-05 19:10:02 UTC

Description of problem:

Currently when trying to add a disk to a VM using the RESTAPI the caller is forced to specify a disk profile if the storage domain has more than one disk profile specified.


Version-Release number of selected component (if applicable):

ovirt-engine-3.5.0.1-1.el6.noarch


How reproducible:

Always.


Steps to Reproduce:

1. Create a storage domain with more than one disk profile, and a VM.

2. Try to add a disk to the VM using the RESTAPI, but without specifying the <disk_profile id="..."/> element:

#!/bin/sh -ex

url="https://ovirt.example.com/ovirt-engine/api";
user="admin@internal"
password="******"

curl \
--verbose \
--insecure \
--request POST \
--user "${user}:${password}" \
--header "Content-Type: application/xml" \
--header "Accept: application/xml" \
--data '
<disk>
  <storage_domains>
    <storage_domain id="00f5dfb8-9068-40c7-99c5-196c67e3ca99"/>
  </storage_domains>
  <size>1</size>
  <type>data</type>
  <bootable>false</bootable>
  <interface>virtio</interface>
  <format>cow</format>
  <sparse>true</sparse>
</disk>
' \
"${url}/vms/7690010b-d3b8-4ad3-8bcd-4a2cc54fc571/disks"


Actual results:

The operation fails with the following result:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<fault>
  <reason>Operation Failed</reason>
  <detail>[action type disk profile empty]</detail>
</fault>

Expected results:

The operation should succeed and automatically select one of the available disk proviles, otherwise existing callers will start failing the moment a new profile is added to the storage domain.

Comment 1 Sven Kieske 2014-11-06 08:51:24 UTC

Isn't this a regression from 3.4 ?

Afaik if no profile is specified the "default" profile should be used.

As this is a regression this should imho block 3.5.1 release.

Comment 2 Juan Hernández 2014-11-06 08:53:37 UTC

Yes, it is a regression.

Comment 3 Roy Golan 2014-11-19 15:25:32 UTC

(In reply to Juan Hernández from comment #2)
> Yes, it is a regression.

1st the disk profiles are not exposed to rest. this should be fixed 

2nd well that's a new feature and I don't assume a user would like us to pick a profile for him. user would still have to choose.

Comment 4 Juan Hernández 2014-11-19 15:32:31 UTC

Disks profiles are exposed, in the top level "diskprofiles" collection.

Callers that are not aware of this feature shouldn't fail. We do need to pick a profile automatically for them, otherwise we are breaking backwards compatibility. The backend should designate one of the disk profiles as the "default" and use it automatically when no one has been explicitly specified by the caller. This default can just be the first profile added, or you may want to add support to the RESTAPI so that the caller may (in a separate call) specify what is the default disk profile (for a data center or storage domain). Whatever we do a request to create a disk that used to work can't suddenly stop working.

Comment 5 Sandro Bonazzola 2015-01-15 14:14:42 UTC

This is an automated message: 
This bug should be fixed in oVirt 3.5.1 RC1, moving to QA

Comment 6 Sandro Bonazzola 2015-01-21 16:02:23 UTC

oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.

Comment 7 Eyal Edri 2015-02-26 12:31:37 UTC

this ovirt bug was fixed during 3.5.1 cycle and is included in the build, and therefore should be verified.

Comment 8 Juan Hernández 2015-02-27 09:25:40 UTC

*** Bug 1196972 has been marked as a duplicate of this bug. ***

Comment 9 Jiri Belka 2015-03-05 13:15:52 UTC

ok, rhevm-backend-3.5.1-0.1.el6ev.noarch

> [...]  This default can just be the first profile added [...]

works as described

Comment 11 Sandro Bonazzola 2015-09-04 12:47:40 UTC

This is an automated message.
oVirt 3.5.4 has been released on September 3rd 2015 and should include the fix for this BZ. Moving to closed current release.