Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1158358

Summary: Deactivate hosts with running vms behaves differently in SDK and REST
Product: Red Hat Enterprise Virtualization Manager Reporter: Raz Tamir <ratamir>
Component: ovirt-engineAssignee: Nobody <nobody>
Status: CLOSED NOTABUG QA Contact:
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.4.3CC: ecohen, gklein, iheim, lpeer, lsurette, michal.skrivanek, ofrenkel, ratamir, rbalakri, Rhev-m-bugs, yeylon
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: virt
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-11-19 10:06:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
engine log none

Description Raz Tamir 2014-10-29 07:57:34 UTC
Created attachment 951658 [details]
engine log

Description of problem:
Found in automation run: http://jenkins.qa.lab.tlv.redhat.com:8080/job/Developer-job-ratamir/702/consoleFull

At 2014-10-28 20:19:25,349 the spm host is deactivate (rest api) and the operation succeeded.

At 2014-10-28 20:32:09,194 the spm is deactivate (sdk api) and the operation is blocked with CDA: "The following Hosts have running VMs and cannot be switched to maintenance mode: 10.35.110.11."

In engine log:
"CanDoAction of action MaintenanceNumberOfVdss failed. Reasons:VAR__TYPE__HOST,VAR__ACTION__MAINTENANCE,CANNOT_MAINTENANCE_VDS_RUN_VMS_NO_OTHER_RUNNING_VDS,$ClustersList cluster_iscsi_storage_cov,$HostsList 10.35.110.11
"




Version-Release number of selected component (if applicable):
vdsm-4.14.17-1.el6ev.x86_64


How reproducible:
100%

Steps to Reproduce:
1. Deactivate spm with running HA vms
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Juan Hernández 2014-11-03 09:34:58 UTC
Looking at the art_test_runner.log file I see that the first time, directly with the REST API, the "deactivate" action was invoked with the following XML document:

  <action>
    <async>false</async>
    <grace_period>
      <expiry>10</expiry>
    </grace_period>
  </action>

And the second time, with the Python SDK, it was invoked with the following XML document:

  <action>
    <async>false</async>
    <grace_period>
      <expiry>10</expiry>
    </grace_period>
  </action>

Exactly the same, so there is no difference between direct call and the Python SDK call, thus we can take the Python SDK out of the picture.

The RESTAPI always does the same in this case: it runs the MaintenanceNumberOfVdss action. Like this:

  public Response deactivate(Action action) {
    return doAction(
      VdcActionType.MaintenanceNumberOfVdss,
      new MaintenanceNumberOfVdssParameters(asList(guid), false),
      action
    );
  }

There is little room there for differences between calls with the same arguments, so if there is a difference it must be in the state of the involved host, and this is managed by the backend and by VDSM, not by the RESTAPI.

Comment 2 Michal Skrivanek 2014-11-07 13:04:04 UTC
this looks like a timing issue of previous test. Please check the conditions before you run the test and/or try to invoke it separately

Comment 3 Raz Tamir 2014-11-11 15:57:15 UTC
Hi Michal,
What condition should I check?

Comment 4 Michal Skrivanek 2014-11-11 19:35:30 UTC
Of the environment. Check that the state of the host corresponds to what the test expects. I'd suspect if you run it separately/manually it will work

Comment 5 Raz Tamir 2014-11-17 07:30:40 UTC
Hi Micahl,
Thanks, you were right