cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Tutkowski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing
Date Tue, 02 Sep 2014 16:51:21 GMT

    [ 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)

Mime
View raw message