Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Tue, 2 Sep 2014 16:51:21 +0000 (UTC)
From: "Mike Tutkowski (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12738410.1409662425000.10029.1409676681596@Atlassian.JIRA>
In-Reply-To: <JIRA.12738410.1409662425000@Atlassian.JIRA>
References: <JIRA.12738410.1409662425000@Atlassian.JIRA>
 <JIRA.12738410.1409662425774@arcas>
Subject: [jira] [Commented] (CLOUDSTACK-7467)
 TestVolumes.test_07_resize_fail failing
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118341#comment-14118341 ] 

Mike Tutkowski commented on CLOUDSTACK-7467:
--------------------------------------------

Thanks for bringing this to my attention.

So, the change I put in was to examine the disk offering ID, if any, that is passed in (we'll call this the new disk offering ID). If the new disk offering ID is not null and it is the same disk offering ID as the current disk offering ID of the volume in question, then we "pretend" like you passed in null for the new disk offering ID (rather than having the current and new disk offering IDs be equal).

It seems that this part of the test is trying to change the size of a volume when the volume's disk offering ID is not customizable.

It looks like the old logic path would ignore the size that you passed into the API in favor of the fixed size of the "new" disk offering ID.

The new logic throws an exception, though.

Can you tell me if my analysis is correct here (i.e. you used to not get an exception, but now you do)?

If so, I'm thinking the new logic is better than the old logic because it seems this test case was missing a problem (it was expecting the resize to work (i.e. not throw an exception), but in reality the test was ignoring the newly passed-in size and setting the size of the volume to be the same as it currently is).

> TestVolumes.test_07_resize_fail failing
> ---------------------------------------
>
>                 Key: CLOUDSTACK-7467
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Volumes
>    Affects Versions: 4.5.0
>            Reporter: Alex Brett
>            Assignee: Mike Tutkowski
>             Fix For: 4.5.0
>
>         Attachments: management-server.log, runinfo.txt
>
>
> Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32) has caused the BVT test integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start failing with:
> {noformat}
> ======================================================================
> ERROR: Test resize (negative) non-existent volume
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/root/cloudstack/test/integration/smoke/test_volumes.py", line 591, in test_07_resize_fail
>     self.apiClient.resizeVolume(cmd)
>   File "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py", line 1716, in resizeVolume
>     response = self.connection.marvinRequest(command, response_type=response, method=method)
>   File "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 379, in marvinRequest
>     raise e
> Exception: Job failed: {jobprocstatus : 0, created : u'2014-09-02T12:19:32+0000', cmd : u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid : u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype : u'object', jobresult : {errorcode : 530, errortext : u"To change a volume's size without providing a new disk offering, its current disk offering must be customizable or it must be a root volume."}, accountid : u'71a306cc-3296-11e4-b130-0a474b082b17'}
> -------------------- >> begin captured stdout << ---------------------
> === TestName: test_07_resize_fail | Status : EXCEPTION ===
> {noformat}
> From what I can see here the test is providing a diskofferingid in its command, so the error text doesn't appear to make sense, but I'm not hugely familiar with this area so it is possible the test has always been doing something wrong...
> I'll attach the full runinfo.txt and management server log from a run to this ticket - assigning initially to Mike Tutkowski as the author of the above commit...


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)