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
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
No disk profiles
A default unlimited disk profile per domain
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: "
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
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
*** 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.