Bug 994569 - REST - storage domains are created by default with format V1
REST - storage domains are created by default with format V1
Status: CLOSED CURRENTRELEASE
Product: oVirt
Classification: Community
Component: ovirt-engine-core (Show other bugs)
3.3
Unspecified Unspecified
unspecified Severity medium
: ---
: 3.5.0
Assigned To: Alissa
Aharon Canan
storage
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-07 10:02 EDT by Alissa
Modified: 2016-02-10 13:28 EST (History)
5 users (show)

See Also:
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 08:03:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
scohen: needinfo+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 17782 None None None Never

  None (edit)
Description Alissa 2013-08-07 10:02:49 EDT
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 11:50:04 EDT
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 04:26:23 EDT
(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 04:58:11 EDT
(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 10:38:42 EDT
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 10:50:26 EDT
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 08:03:59 EDT
Based on comment 5, closing deferred until we start supporting API with versioning.
Comment 7 Allon Mureinik 2014-12-13 12:12:39 EST
This was actually fixed for DATA domain's in 3.5.

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