Description of problem: Storage profiles are only usable in 3.5 DCs - so upgrading a DC from 3.x to 3.5 should create a deafault, unlimited storage profile for each domain under the DC. Version-Release number of selected component (if applicable): engine built from source with commit hash cf7b1700eb77672cc34f7177e83c7250817de74b How reproducible: 100% Steps to Reproduce: 1. Create a 3.0 DC 2. Create a cluster 3. Add a host to the cluster with ovirt-3.5's VDSM 4. Add a storage domain 5. Upgrade the cluster to 3.5 6. Upgrade the DC to 3.5 Actual results: No disk profiles Expected results: A default unlimited disk profile per domain Additional info:
How could this bug not be found by automatic tests? I was under the impression a full upgrade plus full lifecycle gets tested before each release? imho this is a regression from 3.4 because you can't create new disks on new DCs.
This bug got introduced because of incomplete release criteria: "MUST: Fully operational flow (define DC hierarchy so you can run vm) with GUI/CLI/Python-API/REST-API " "MUST: Upgrade from previous release Features/bug list: " from: http://www.ovirt.org/OVirt_3.5_release-management#Release_Criteria_.28WIP.29 So these things get tested independent but not in combination. imho it makes sense to alter the release criteria for 3.6: MUST: Upgrade from previous release MUST: Fully operational flow (define DC hierarchy so you can run vm) with GUI/CLI/Python-API/REST-API This simple automatic test would have revealed the bug before GA: 1. Spin up latest release 2. Upgrade to RC 3. define DC hierarchy so you can run vm HTH
*** Bug 1154688 has been marked as a duplicate of this bug. ***
*** Bug 1175255 has been marked as a duplicate of this bug. ***
This is an automated message: This bug should be fixed in oVirt 3.5.1 RC1, moving to QA
oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.