Description of problem: Currently it is impossible to specify the SD format (i.e. ovirt sdk types.StorageFormat.V4) when creating a storage domain. The implementation is lacking an option to pass 'storage_format' to the API: https://github.com/oVirt/ovirt-ansible-collection/blob/master/plugins/modules/ovirt_storage_domain.py This is useful if the SD being created is going to be attached to a DC which is not of the latest Compatibility Level (i.e. 4.3 engine with 4.2/4.1 DC), so the user can create it with a compatible version.
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.
This can also be used by BZ1932149 as one way to fix it.
Moving back to 4.5.0, I think it can enter the release. PR merged, moving to MODIFIED. QE: See 'ansible-doc -t module ovirt_storage_domain' and the example I added there if you want to verify this bug directly. I think it's enough to verify the depending bug 1932149, I'll comment there with details. It's important to note that while the code I added/changed supports in theory all storage formats - 'v1', 'v2', 'v3', 'v4' and 'v5' - recent engines support only 'v4' and 'v5'. See [1] for the commit that removed support for 'v3', merged in 4.3. [1] https://github.com/oVirt/ovirt-engine/commit/373c3f8e
*** Bug 1945114 has been marked as a duplicate of this bug. ***
During adding storage domain there was V4 but after activation it changed to V5. Is it desired behavior? Compatibility version of the cluster and the data center is 4.7 ovirt-ansible-collection-2.0.3-1.el8ev.noarch ovirt-engine-4.5.0.6-0.7.el8ev.noarch
(In reply to Barbora Dolezalova from comment #19) > During adding storage domain there was V4 but after activation it changed to > V5. > Is it desired behavior? No idea, Nir? Sounds somewhat weird to me, but perhaps that's intended. > > Compatibility version of the cluster and the data center is 4.7 Perhaps try with both set to 4.2. I only tested the patch for current bug as part of verifying bug 1932149.
(In reply to Yedidyah Bar David from comment #20) > (In reply to Barbora Dolezalova from comment #19) > > During adding storage domain there was V4 but after activation it changed to > > V5. > > Is it desired behavior? > > No idea, Nir? Sounds somewhat weird to me, but perhaps that's intended. When attaching a storage domain with version < 5, vdsm will convert it to 5. Engine UI prevent creation of storage domains with version < 5 if hosts support storage domain version 5. I don't think it it make sense to create storage domains using non default version. If you want older storage domain so it is compatible with older system, create the storage domain on an older system.
I tested it with the cluster and the data center in version 4.2 and the storage domain is V4, but it is limited by the version of the cluster/data center. If the user wants to specify the storage domain format (V3, V4, V5...) it always will be the latest supported version in the end so why do we need the parameter for that?
(In reply to Barbora Dolezalova from comment #22) > I tested it with the cluster and the data center in version 4.2 and the > storage domain is V4, but it is limited by the version of the cluster/data > center. I do not understand. AFAIU from the dependent bug 1932149, the minimal flow is: 1. Set up a 4.4 (or 4.3, for that matter) engine 2. Create a DC/cluster at 4.2 level 3. Create an unattached storage domain without passing format - the parameter was not available at the time. 4. Activate the storage domain. You can see the flow here: https://github.com/oVirt/ovirt-ansible-collection/blob/master/roles/hosted_engine_setup/tasks/create_storage_domain.yml You can also see the history of this file, press "History" there. As you can see, for the current patch, we added some preparation tasks to get info, but the only changes to the actual creation, were to pass storage_format. So: What flow did you test? Did you try to create a storage domain in a 4.2 DC/cluster (in 4.4 or 4.5 engine), without passing storage_format, and it was created as V4? If so, perhaps you didn't pass 'state: unattached'. Perhaps try that. Thanks. > > If the user wants to specify the storage domain format (V3, V4, V5...) it > always will be the latest supported version in the end so why do we need the > parameter for that? See the dependent bug. The SD was created with V5, even though the DC/cluster were at 4.2, and activation of it failed.
(In reply to Yedidyah Bar David from comment #23) > (In reply to Barbora Dolezalova from comment #22) > > I tested it with the cluster and the data center in version 4.2 and the > > storage domain is V4, but it is limited by the version of the cluster/data > > center. > > I do not understand. AFAIU from the dependent bug 1932149, the minimal flow > is: > > 1. Set up a 4.4 (or 4.3, for that matter) engine > 2. Create a DC/cluster at 4.2 level > 3. Create an unattached storage domain without passing format - the > parameter was not available at the time. > 4. Activate the storage domain. > > You can see the flow here: > > https://github.com/oVirt/ovirt-ansible-collection/blob/master/roles/ > hosted_engine_setup/tasks/create_storage_domain.yml > > You can also see the history of this file, press "History" there. As you can > see, for the current patch, we added some preparation tasks to get info, but > the only changes to the actual creation, were to pass storage_format. > > So: What flow did you test? > > Did you try to create a storage domain in a 4.2 DC/cluster (in 4.4 or 4.5 > engine), without passing storage_format, and it was created as V4? If so, > perhaps you didn't pass 'state: unattached'. Perhaps try that. Thanks. > > > > > If the user wants to specify the storage domain format (V3, V4, V5...) it > > always will be the latest supported version in the end so why do we need the > > parameter for that? > > See the dependent bug. The SD was created with V5, even though the > DC/cluster were at 4.2, and activation of it failed. Yes, I did tested this flow. The question was if the version should stay as specified by the new parameter or as Nir mentioned in the comment #21, that the version moves to compatibility version of data center.
(In reply to Barbora Dolezalova from comment #24) > Yes, I did tested this flow. Which one, exactly? With DC/cluster at compat 4.2 and unattached?
(In reply to Yedidyah Bar David from comment #25) > (In reply to Barbora Dolezalova from comment #24) > > Yes, I did tested this flow. > > Which one, exactly? With DC/cluster at compat 4.2 and unattached? 1. Set up a 4.5 engine 2. Create a DC/cluster at 4.2 level 3. Create an unattached storage domain with and without passing format 4. Activate the storage domain.
Thanks. So I do not understand how bug 1932149 was verified. Nir, does this make sense to you? What's the difference? The screenshot attached there was most likely taken after deployment was finished, so if the engine/vdsm/whatever changes the format to V5, this was either too slow to be represented in the screenshot, or did not happen at all.
(In reply to Yedidyah Bar David from comment #27) > Thanks. > > So I do not understand how bug 1932149 was verified. Following these steps: https://bugzilla.redhat.com/show_bug.cgi?id=1932149#c20 You can also see the screenshots from the very same bug. https://bugzilla.redhat.com/attachment.cgi?id=1871368 >
Nikolai, do you remember how much time passed between finishing the deployment/restore and taking the screenshot? Thanks.
(In reply to Yedidyah Bar David from comment #29) > Nikolai, do you remember how much time passed between finishing the > deployment/restore and taking the screenshot? Thanks. Once I was able to log in to the engine right after the restore finished, as the deployment always checks for the liveliness of the engine, I assume that it took me two minutes or so.
(In reply to Nikolai Sednev from comment #30) > (In reply to Yedidyah Bar David from comment #29) > > Nikolai, do you remember how much time passed between finishing the > > deployment/restore and taking the screenshot? Thanks. > > Once I was able to log in to the engine right after the restore finished, as > the deployment always checks for the liveliness of the engine, I assume that > it took me two minutes or so. Nir, how does the automatic conversion to V5 work? Is it immediate? Async? How often? Is it possible that it also happened for Nikolai in bug 1932149, but deployment was quick enough so succeeded right before the conversion? And also Nikolai was quick enough so managed to take a screenshot with V4?
And, most importantly: Does it happen regardless of the compat level? And if so, is it still safe to assume that bug 1932149 is fixed, or might the conversion happen automatically between the creation and the activation, causing the activation to fail?
(In reply to Yedidyah Bar David from comment #31) > (In reply to Nikolai Sednev from comment #30) > > (In reply to Yedidyah Bar David from comment #29) > > > Nikolai, do you remember how much time passed between finishing the > > > deployment/restore and taking the screenshot? Thanks. > > > > Once I was able to log in to the engine right after the restore finished, as > > the deployment always checks for the liveliness of the engine, I assume that > > it took me two minutes or so. > > Nir, how does the automatic conversion to V5 work? Is it immediate? Async? > How often? Is it possible that it also happened for Nikolai in bug 1932149, > but deployment was quick enough so succeeded right before the conversion? > And also Nikolai was quick enough so managed to take a screenshot with V4? The conversion happens when - the SPM is started: https://github.com/oVirt/vdsm/blob/da7e08d713df3c9888c56ea9a620c7e19228b3aa/lib/vdsm/storage/sp.py#L344 This upgrade all domains to specific version, or to the master domain version - when activating a storage domain https://github.com/oVirt/vdsm/blob/da7e08d713df3c9888c56ea9a620c7e19228b3aa/lib/vdsm/storage/sp.py#L1205 The system is designed to use the same domain version in all storage domains in a DC. If the master storage domain is v4, adding a new domain using v3 will upgrade it to v4 when the domain is activated. If the master storage domain is v5, adding a new domain using v3 or v4 will upgrade it to v5 when the domain is activated. I'm not sure what is the use case for creating a storage domain with a specific version. The UI tries hard to make this impossible or hard. Why are we spending time on this?
(In reply to Nir Soffer from comment #36) > I'm not sure what is the use case for creating a storage domain with a > specific version. > The UI tries hard to make this impossible or hard. Why are we spending time > on this? Please see bug 1932149. Can you suggest a better solution? Thanks.
(In reply to Yedidyah Bar David from comment #37) > (In reply to Nir Soffer from comment #36) > > I'm not sure what is the use case for creating a storage domain with a > > specific version. > > The UI tries hard to make this impossible or hard. Why are we spending time > > on this? > > Please see bug 1932149. Can you suggest a better solution? Thanks. If you want to create a v3/v4 storage domain you need to make sure the master storage domain is using the same version. I'm not sure this is possible with the current engine. Benny, do we support it in engine?
We also tested creating master storage domain v4, adding storage via ansible works as described Comment 36. So parameter storage_format works. Feel free to create new bug for changing automatically the version if that is not intended. Verified in ovirt-ansible-collection-2.0.3-1.el8ev.noarch, ovirt-engine-4.5.0.6-0.7.el8ev.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (RHV RHEL Host (ovirt-host) [ovirt-4.5.1] update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:5583