| Summary: | Wrong cluster in "Edit host" dialog | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Michael Burman <mburman> | ||||
| Component: | Frontend.WebAdmin | Assignee: | Alexander Wels <awels> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Michael Burman <mburman> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 4.1.0 | CC: | bugs, mburman, myakove, oourfali, yzaspits | ||||
| Target Milestone: | ovirt-4.1.0-alpha | Flags: | rule-engine:
ovirt-4.1+
rule-engine: planning_ack+ rule-engine: devel_ack+ pstehlik: testing_ack+ |
||||
| Target Release: | 4.1.0 | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-02-01 14:55:16 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
On 4.0.5-0.1.el7ev it is working as expected, on master it is not working. If happens only on OVS type then probably should be looked at by the network team. Dan - please move back if needed. Michael, could you please attach logs? Created attachment 1208578 [details]
Logs
The problem seems to be because when opening the edit dialog, the Host cluster that reported for the host is incorrect and that is why we failing to apply a change for comment. Engine think we trying to change the host cluster while the host is still up. Looks like the issue is in "Edit host" dialog that displays wrong cluster (and does not allow to fix that) and after submitting the change, the backend rightfully thinks that the user requested moving the host to another cluster and prevents the change as it should do in such situation. Michael, could you re-check the scenario with a non-OVS cluster? I'd say the issue isn't OVS related. Yevgeny i can confirm that it's not related to ovs. It's a bug in edit host dialog indeed, looks like it always displaying the first cluster in the list, the wrong cluster and not the one that the host is actually running in. New steps to reproduce as it doesn't relevant to ovs clusters only. See comments 5, 6, 7 1) Create 3 clusters - CL1, CL2, CL3 2) Add host to cluster CL1 3) Move host to cluster CL2 4) Edit host while it's up and operational in cluster CL2 5) You will see that the host displayed in a wrong cluster CL1 and not as should be on CL2. If we will try to add a comment we will fail, because engine backend thinks we trying to move the host to other cluster while it's up. 6) Move host to cluster CL3 7) Edit host while it's up and operational in cluster CL3 8) You will see that the host displayed in a wrong cluster CL1 and not as should be on CL3. I guess that, the problem isn't related to the host being up, but that happens to any host that is in a cluster that isn't the first in the list. Being in status other than 'Maintenance' makes the cluster field immutable. But this bug could lead a user to making drastic changes to a host he don't really wants. Like that has happened to Michael, a user could submit changing host's cluster without understanding what he requests. Alexander, can you take a look? Interesting, it appears the new list box was the culprit in the display. But as far as I could tell, the model had the correct value, so not sure why it would reject the update. The fix for this issue should be included in oVirt 4.1.0 beta 1 released on December 1st. If not included please move back to modified. Verified on - 4.1.0-0.2.master.20161214234138.gitc23fdcc.el7.centos |
Description of problem: [OVS] - Can't add or update the 'Comment' for hosts in a 'ovs' switch type clusters. It is not possible to add a comment for a host in an ovs type clusters. Error while executing action: camel-vdsa.qa.lab.tlv.redhat.com: Cannot edit Host. Host parameters cannot be modified while Host is operational. Please switch Host to Maintenance mode first. 2016-10-09 09:51:43,201 WARN [org.ovirt.engine.core.utils.ObjectIdentityChecker] (default task-14) [2a7fa4ff] Field 'clusterId' can not be updated when status is 'Up' 2016-10-09 09:51:43,201 WARN [org.ovirt.engine.core.bll.ChangeVDSClusterCommand] (default task-14) [2a7fa4ff] Validation of action 'ChangeVDSCluster' failed for user admin@internal-authz. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__HOST,VDS_STATUS_NOT_VALID_FOR_UPDATE 2016-10-09 09:51:43,201 INFO [org.ovirt.engine.core.bll.ChangeVDSClusterCommand] (default task-14) [2a7fa4ff] Lock freed to object 'EngineLock:{exclusiveLocks='[20483bbb-8d31-4503-9548-c1c7ac4f6425=<VDS, ACTION_TYPE_FAILED_OBJECT_LOCKED>]', sharedLocks='null'}' 2016-10-09 09:55:04,176 INFO [org.ovirt.engine.core.bll.ChangeVDSClusterCommand] (default task-16) [66baf285] Lock Acquired to object 'EngineLock:{exclusiveLocks='[20483bbb-8d31-4503-9548-c1c7ac4f6425=<VDS, ACTION_TYPE_FAILED_OBJECT_LOCKED>]', sharedLocks='null'}' 2016-10-09 09:55:04,176 WARN [org.ovirt.engine.core.utils.ObjectIdentityChecker] (default task-16) [66baf285] Field 'clusterId' can not be updated when status is 'Up' 2016-10-09 09:55:04,176 WARN [org.ovirt.engine.core.bll.ChangeVDSClusterCommand] (default task-16) [66baf285] Validation of action 'ChangeVDSCluster' failed for user admin@internal-authz. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__HOST,VDS_STATUS_NOT_VALID_FOR_UPDATE - In legacy type clusters it is working as expected. Version-Release number of selected component (if applicable): 4.1.0-0.0.master.20161008231308.git39b2133.el7.centos How reproducible: 100 Steps to Reproduce: 1. Add host to ovs switch type cluster 2. Try to add a comment to this host - edit the host via the 'Hosts' main tab and add a comment, press 'OK" to approve Actual results: Failed with error - can't edit host while it's operational. Expected results: Add comment to host should work as expected when the host is up and operational, like always was on legacy type clusters