Bug 1311318

Summary: dc.storagedomains.add() causes RequestError
Product: [oVirt] ovirt-engine Reporter: jniederm
Component: BLL.StorageAssignee: Daniel Erez <derez>
Status: CLOSED WORKSFORME QA Contact: Aharon Canan <acanan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 4.0.0CC: amureini, bugs, tnisan
Target Milestone: ovirt-4.0.0-alphaFlags: tnisan: ovirt-4.0.0?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-28 15:33:15 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:
Attachments:
Description Flags
stacktrace.txt
none
relevant part of engine log
none
__do_request method 'body' param none

Description jniederm 2016-02-23 23:03:39 UTC
Created attachment 1129949 [details]
stacktrace.txt

Description of problem:
Calling dc.storagedomains.add(storageDomain) causes following error:
ovirtsdk.infrastructure.errors.RequestError: 
status: 409
reason: Continue
detail: Cannot attach Storage. The relevant Storage Domain is inaccessible.
-Please handle Storage Domain issues and retry the operation.

The error message suggests that the Storage Domain is 'inaccessible' however engine reports it as 'Active' (green triangle up) in webadmin.

Version-Release number of selected component (if applicable):
ovirt-engine-sdk-python.noarch 4.0.0.0-0.2.20151123.git8ba204b.fc22 @ovirt-master-snapshot
engine: self-build, 4.0 master, 904ab61 master
(it differs from bugzilla version field because appropriate version was not offered)

How reproducible:
100%

Steps to Reproduce:
1. Create and activate storage domain named 'Domain1' in DC 'Default'.
2. Execute code (It is expected to have no effect.):

    dc = api.datacenters.get(name='Default')
    storageDomain = api.storagedomains.get('Domain1')
    dc.storagedomains.add(storageDomain)

Actual results:
Stacktrace (attached) + errormessage

Expected results:
Nothing observable, just making sure that storage domain is attached to DC.

Additional info:
The code worked in 3.6

Possible hint (may be misleading):
During debugging it turns out that the method firing exception, ovirtsdk.infrastructure.connectionspool.ConnectionsPool#__do_request, obtains 'body' parameter that looks more like response than request (attached) and presumably violates 'rsdl_metadata.yaml' contract.

Comment 1 jniederm 2016-02-23 23:05:27 UTC
Created attachment 1129951 [details]
relevant part of engine log

Comment 2 jniederm 2016-02-23 23:06:27 UTC
Created attachment 1129953 [details]
__do_request method 'body' param

Comment 3 Juan Hernández 2016-02-24 09:52:24 UTC
The value of the 'body' parameter that you see looks like a request because you sent as request body what you previously got as a response. First you assign to the "storageDomain" variable the response of the "api.storagedomains.get" method. That is the complete representation of the storage domain. Then you are sending that complete representation as parameter. This is bad practice, because you are sending much more than what the server needs, thus wasting network and processing resources, and potentially confusing yourself.

The operation that attaches a storage domain only needs the identifier or name of the storage domain, so you can do this instead:

  storageDomain = ...;
  dc.storagedomains.add(
    params.StorageDomain(id=storageDomain.get_id())
  )

That will result in the following XML document:

  <storage_domain id="..."/>

Anyhow, this isn't related to the problem. Actually, what you see, is the expected behavior of the API and of the SDK: if the backend says that the storage domain can't be attached, then the API and the SDK should just report that accurately.

I'm moving the bug to the backend component.

Comment 4 Red Hat Bugzilla Rules Engine 2016-02-24 10:16:52 UTC
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.

Comment 5 Allon Mureinik 2016-03-28 15:33:15 UTC
Wasn't able to reproduce. If you can, please attach the full logs and explain how you did it.