Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 994569

Summary:	REST - storage domains are created by default with format V1
Product:	[Retired] oVirt	Reporter:	Alissa <abonas>
Component:	ovirt-engine-core	Assignee:	Alissa <abonas>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Aharon Canan <acanan>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	3.3	CC:	acathrow, amureini, iheim, scohen, yeylon
Target Milestone:	---	Flags:	scohen: needinfo+
Target Release:	3.5.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	storage
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	please document in REST api documentation, that when creating a storage domain, user can also pass storage_format as one of the properties. It's documented now in result of domain creation call (what is returned to user), but not in usage example.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-08-25 12:03:59 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alissa 2013-08-07 14:02:49 UTC

Description of problem:
If user doesn't specify storage format property when creating a storage domain (it's created unattached) via REST (it's not documented in documentation so it's likely the user won't specify it), it's created with format V1.
It is not symmetric to webadmin UI, where the default format is V3 when creating an unattached storage domain. User can still select V1, however the default is V3.

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

How reproducible:
always

Steps to Reproduce:
1. create a storage domain via REST
2. observe its properties via REST or webadmin UI - storage_format is V1 
3. open "create storage" dialog in webadmin UI, select DacaCenter=none, create storage domain. its storage_format is V3


Expected results:
same default behavior for REST and webadmin UI.

Additional info:
The reason for the difference is that REST doesn't pass any value to backend, where the default value for format in storageDomainStatic is V1. While webadmin UI has its own default values passed to backend, overriding backend defaults.

Suggested solution:
1. increase default format in backend to V3.
or (less nice):
2. pass default V3 from REST side if user didn't explicitly set storage format value.

Comment 1 Allon Mureinik 2013-08-07 15:50:04 UTC

The description of the current situation is correct.
IMHO, the suggested solution is also correct.

However, note that this is a behavior change (a right one, IMHO, but a change non the less).
Sean - please approve we're OK with this change.

Comment 2 Sean Cohen 2013-08-11 08:26:23 UTC

(In reply to Allon Mureinik from comment #1)
> The description of the current situation is correct.
> IMHO, the suggested solution is also correct.
> 
> However, note that this is a behavior change (a right one, IMHO, but a
> change non the less).
> Sean - please approve we're OK with this change.

Yes, we should have same default behavior for REST and webadmin UI.

Comment 3 Itamar Heim 2013-08-11 08:58:11 UTC

(In reply to Sean Cohen from comment #2)
> (In reply to Allon Mureinik from comment #1)
> > The description of the current situation is correct.
> > IMHO, the suggested solution is also correct.
> > 
> > However, note that this is a behavior change (a right one, IMHO, but a
> > change non the less).
> > Sean - please approve we're OK with this change.
> 
> Yes, we should have same default behavior for REST and webadmin UI.

how does this prevail on not breaking the API for someone that wrote a script?
(specifically here, i'm not sure its a commonly used flow other than in internal testing, but the question is more general)

(and actually, there are places we don't have same behavior, assuming the UI is helping the user with some defaults, while in API the user has to be specific on what they want as they are more advanced capabilities as well).

Comment 4 Allon Mureinik 2013-08-22 14:38:42 UTC

This approach proposed by this bug was rejected by Michael (the REST maintainer):
http://gerrit.ovirt.org/#/c/17782/

I propose closing with WONTFIX.
Sean? Itamar?

Comment 5 Itamar Heim 2013-08-22 14:50:26 UTC

I propose fixing, in a future api version (say, in 4.0, or when the API supports versioning).
but closed deferred can probably be used until then

Comment 6 Allon Mureinik 2013-08-25 12:03:59 UTC

Based on comment 5, closing deferred until we start supporting API with versioning.

Comment 7 Allon Mureinik 2014-12-13 17:12:39 UTC

This was actually fixed for DATA domain's in 3.5.