Bug 1120712 - On data domain creation rest-api should use format V3 by default
Summary: On data domain creation rest-api should use format V3 by default
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.5.0
Assignee: Allon Mureinik
QA Contact: Raz Tamir
URL:
Whiteboard: storage
Depends On:
Blocks: 1118349 rhev3.5beta 1156165 1242092
TreeView+ depends on / blocked
 
Reported: 2014-07-17 14:20 UTC by Federico Simoncelli
Modified: 2016-02-10 18:27 UTC (History)
13 users (show)

Fixed In Version: ovirt-3.5.0_rc1.1
Doc Type: Bug Fix
Doc Text:
Cause: Previously, when creating a storage domain via REST API, if the <storage_format> is not specified, it's implicitly treated as V1. Consequence: V1 is deprecated, and once the domain is attached to any DC with compatibility level > 3.0, it's upgraded to V3. This is both time consuming and error-prone. Fix: The default for DATA DOMAIN has been changed, and when creating a storage domain via REST API, if the <storage_format> is not specified, it's implicitly treated as V3. Result: Behavior change, as described above.
Clone Of:
Environment:
Last Closed:
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 30960 0 master MERGED core: Calculate storage format when adding an SD Never
oVirt gerrit 31348 0 ovirt-engine-3.5 MERGED core: Calculate storage format when adding an SD Never

Description Federico Simoncelli 2014-07-17 14:20:34 UTC
Description of problem:
It is time to switch the data domain default version to V3 on creation. WebAdmin is already prompting V3 as default but REST-API it is not yet using V3 when the format is not specified, e.g.:

<storage_domain>
    <name>iscsi_0</name>
    <type>data</type>
    <storage>
        <type>iscsi</type>
        <logical_unit id="...">
            <port>3260</port>
            <target>...</target>
            <address>...</address>
        </logical_unit>
    </storage>
    <host>
        <name>...</name>
    </host>
</storage_domain>

Version-Release number of selected component (if applicable):
ovirt-engine-3.5.0-0.0.master.20140629172257.git0b16ed7.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. Create a data storage domain using rest-api and not specifying the storage_format

Actual results:
Created domain is V1

Expected results:
Created domain should be V3

Additional info:
This should be tested both for file and block domains.

Comment 1 Juan Hernández 2014-07-17 14:33:46 UTC
The RESTAPI doesn't decide what is the default format, it just passes to the backend what the caller provided. If the caller doesn't provide a value for the format then it will have the default value, as assigned in the constructor of the StorageDomainStatic class.

Before changing the default please take into consideration the possible backwards compatibility issues.

Comment 2 Allon Mureinik 2014-07-17 16:08:01 UTC
(In reply to Juan Hernández from comment #1)
> Before changing the default please take into consideration the possible
> backwards compatibility issues.

Changing the ctor is small-change. As you said - the issue is backwards compatibility.

The main issue I'm concerned about is creating ISO and Export domains, which, AFAIK, should be V1.
Is this bug really worth the risk?

Comment 3 Juan Hernández 2014-07-17 16:21:38 UTC
(In reply to Allon Mureinik from comment #2)
> The main issue I'm concerned about is creating ISO and Export domains,
> which, AFAIK, should be V1.
> Is this bug really worth the risk?

I really don't know what are the effects of changing the default, and to be on the safe side I'd say it isn't worth the risk.

Comment 4 Federico Simoncelli 2014-07-17 23:16:37 UTC
(In reply to Juan Hernández from comment #3)
> (In reply to Allon Mureinik from comment #2)
> > The main issue I'm concerned about is creating ISO and Export domains,
> > which, AFAIK, should be V1.
> > Is this bug really worth the risk?
> 
> I really don't know what are the effects of changing the default, and to be
> on the safe side I'd say it isn't worth the risk.

Maybe it's not clear what happens. By default (when not specified) you create a storage domain V1 and as soon as you attach it to a data-center >= 3.1 it gets updated.

Version V1 is obsolete and shouldn't be used. To make a comparison this is like formatting a device with ext2 and then convert it to ext3 and ext4.

If you really want a V1 data domain (discouraged) you can still do it explicitly requesting the format.

Moreover when we'll drop 3.0 we'll just have data domains V3 so sooner or later this has to change.

Comment 5 Raz Tamir 2014-08-24 14:31:06 UTC
Verified on - ovirt-engine-3.5.0-0.0.master.20140821064931.gitb794d66.el6.noarch

Response body (REST api):
...
<storage_format>v3</storage_format>
...

Also in webadmin storage format is V3

Comment 6 Tal Nisan 2014-11-26 11:23:03 UTC
Please supply doc text

Comment 7 Allon Mureinik 2015-02-16 19:12:28 UTC
RHEV-M 3.5.0 has been released, closing this bug.

Comment 8 Allon Mureinik 2015-02-16 19:12:29 UTC
RHEV-M 3.5.0 has been released, closing this bug.


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