Thanks
-min

On 3/17/14 10:39 PM, "Marcus" <shadow...@gmail.com> wrote:

>This commit in 4.4 should fix it (cherry picked to master as well):
>
>commit 8eed3c5113d1141be820077e121db802566faec6
>Author: Marcus Sorensen <mar...@betterservers.com>
>Date:   Fri Mar 14 07:13:34 2014 -0600
>
>    Change newly added details map for deployVirtualMachine to an empty
>    map, instead of passing all possible keys as empty values
>
>diff --git a/tools/marvin/marvin/integration/lib/base.py
>b/tools/marvin/marvin/integration/lib/base.py
>index ca9f2b4..38e8568 100755
>--- a/tools/marvin/marvin/integration/lib/base.py
>+++ b/tools/marvin/marvin/integration/lib/base.py
>@@ -413,7 +413,7 @@ class VirtualMachine:
>         if "userdata" in services:
>             cmd.userdata = base64.urlsafe_b64encode(services["userdata"])
>
>-        cmd.details = [{"cpuNumber":
>"","cpuSpeed":"","memory":"","rootdisksize":""}]
>+        cmd.details = [{}]
>
>         if customcpunumber:
>             cmd.details[0]["cpuNumber"] = customcpunumber
>
>On Mon, Mar 17, 2014 at 11:26 PM, Marcus <shadow...@gmail.com> wrote:
>> Looks like all of the items in 'details' are getting added to the API
>> call as empty params:
>>
>> GET 
>>/client/api?domainid=7193957c-ab53-11e3-a79c-000c29d82947&zoneid=bfc93d0d
>>-9531-4648-9d04-ca1f47fcd5a6&apiKey=8d6jxAVly_B6asBBjuL5S5bxXzNhx3CyiPLCJ
>>Q7Qa4hti3HLlQQkP-x-ayenmO6t8vfZt5nDRHixsJc7XKdIGA&details%5B0%5D.rootdisk
>>size=&serviceofferingid=80bc069b-8283-4357-a995-e429d34b65d6&displayname=
>>Test+VM&signature=fHopjtezyTNYP2zPU4rHySxt%2FnM%3D&details%5B0%5D.cpuNumb
>>er=&templateid=719528ec-ab53-11e3-a79c-000c29d82947&response=json&details
>>%5B0%5D.memory=&account=test-TestDeployVM-test_deploy_vm_multiple-QTF0VD&
>>name=testvm&details%5B0%5D.cpuSpeed=&command=deployVirtualMachine&hypervi
>>sor=kvm
>> HTTP/1.1
>>
>> I've changed the default details map to be empty, instead of defining
>> all possible details as having empty strings as the original commit
>> did. Testing now and will commit if it works. I hope it doesn't break
>> *their* tests...
>>
>> commit 3f7b628c707cd9c30542efd670416be5fbb473f0
>> Author: Gaurav Aradhye <gaurav.arad...@clogeny.com>
>> Date:   Fri Feb 28 01:46:24 2014 -0500
>>
>>     CLOUDSTACK-6147: Adding first set of test caess for Dynamic
>> Compute Offering feature
>>
>>     Signed-off-by: SrikanteswaraRao Talluri <tall...@apache.org>
>>
>>
>> On Mon, Mar 17, 2014 at 11:01 PM, Marcus <shadow...@gmail.com> wrote:
>>> I'll take a look. I wasn't the one who added the details map to
>>> base.py, although I did add to it and can probably figure out what's
>>> wrong. The original commit didn't change any deployVirtualMachine
>>> calls. Can you give me an example of a test that is faling? Is it
>>> test_deploy_vm.py?
>>>
>>> On Mon, Mar 17, 2014 at 5:43 PM, Min Chen <min.c...@citrix.com> wrote:
>>>> Hi Marcus,
>>>>
>>>>         I found an issue with this merge, my previous marvin test is
>>>>broken in
>>>> deployVirtualMachine if no rootdisksize is passed. All previous marvin
>>>> tests are written without passing this parameter. Can you take a look
>>>>at
>>>> base.py to make sure that old marvin tests without passing those
>>>>custom
>>>> parameters are still working fine?
>>>>
>>>>         Thanks
>>>>         -min
>>>>
>>>> On 3/11/14 1:17 PM, "Marcus" <shadow...@gmail.com> wrote:
>>>>
>>>>>I'd like to merge the resize-root branch for the requested feature of
>>>>>being able to resize root volumes. I have pulled from master and
>>>>>tested.
>>>>>
>>>>>I should note that this feature is affected by an existing bug in
>>>>>master that was introduced recently, breaking the existing data disk
>>>>>resize feature on Ubuntu 12.04 + stock libvirt, but has otherwise been
>>>>>tested to work with Ubuntu 12.04 + recent libvirt and CentOS 6.4,6.5.
>>>>>We are discussing how to proceed with that separate issue on-list.
>>>>>
>>>>>Integration tests were added for deploy in a new file
>>>>>"test_deploy_vm_root_resize.py" and existing resize tests were
>>>>>extended to root volumes in the existing test_volumes.py.
>>>>>
>>>>>Findbugs indicates there are no new issues introduced (220/220), as
>>>>>reported by running the following on both master and resize-root. This
>>>>>was just my stab in the dark at trying to make sense of the output in
>>>>>absence of familiarity with findbugs:
>>>>>
>>>>># mvn -P enablefindbugs verify
>>>>># find . -name findbugs.xml -exec xmllint --format {} \; | grep -c
>>>>>BugInstance
>>>>>
>>>>>FS:
>>>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Root+Resize+Sup
>>>>>port
>>>>>JIRA: https://issues.apache.org/jira/browse/CLOUDSTACK-6181
>>>>

Reply via email to