Bug 834890
Summary: | webadmin: CanDoAction of action UpdateStoragePool failure is not propagated to the UI | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Yaniv Kaul <ykaul> |
Component: | ovirt-engine-webadmin-portal | Assignee: | Asaf Shakarchi <asaf> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Daniel Paikov <dpaikov> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.1.0 | CC: | abaron, acathrow, amureini, bazulay, dyasny, ecohen, hateya, iheim, jkt, Rhev-m-bugs, ykaul, yzaslavs |
Target Milestone: | --- | ||
Target Release: | 3.1.0 | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | storage | ||
Fixed In Version: | si13 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-12-04 20:06:04 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Yaniv Kaul
2012-06-24 15:15:00 UTC
1 - Basically this action (change storage type of DC) should not be permitted. 2 - There are 2 cases it may logically make sense * when created it by mistake (before assigning it storage domains and hosts), and in this case the correction should be deletion and recreation. * after adding hosts to a cluster and before assigning SDs to it possible moving the hosts one by one to another cluster within another DC (this time with the right storage type) .... time consuming Bottom line I think this should be solved by disabling editing the DC storage type. By the way I cannot reproduce this issue, I just tested and it seems like the error is actually propagated to the UI properly, Maybe it was fixed at some point. please answer Barak's comment so I can know how to proceed. I disagree with Barak here as user might have defined networks and would like not to repeat the work (let's say everything is defined but storage is being migrated). However, going forward we will remove the storage type limitation altogether so it doesn't look worth it enabling this. Unless this is a regression (i.e. this was possible in a previous version) fix should be to block the operation. Yaniv? (In reply to comment #1) > 1 - Basically this action (change storage type of DC) should not be > permitted. > 2 - There are 2 cases it may logically make sense > * when created it by mistake (before assigning it storage domains and > hosts), and in this case the correction should be deletion and > recreation. That's ugly. Delete and re-creating is an obvious workaround for this BZ. This BZ is about not needing to perform this workaround. However, if you do not wish to fix, then indeed disabling the edit (or disallowing to change the type) is a second best option. Acking for greying out the DC type box when there are storage domains in DC. Patch submitted: http://gerrit.ovirt.org/#/c/6624/ Committed [9943eeb946c18572] the following error is propagated to UI: error: Default Cluster cannot be moved to the Data Center that has local Storage. 2012-08-06 21:27:38,309 WARN [org.ovirt.engine.core.bll.storage.UpdateStoragePoolCommand] (ajp-/127.0.0.1:8009-11) [161e2a7] CanDoAction of action UpdateStoragePool failed. Reasons:VAR__TYPE__STORAGE__POOL,ACTION_TYPE_FAILED_STORAGE_POOL_WITH_DEFAULT_VDS_GROUP_CANNOT_BE_LOCALFS,VAR__ACTION__UPDATE |