date:20140214


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Harikrishna Patnala updated CLOUDSTACK-6075:


Status: Reviewable  (was: In Progress)

 Increase the ram size for router service offering 
 --

 Key: CLOUDSTACK-6075
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6075
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: Harikrishna Patnala
Assignee: Harikrishna Patnala
 Fix For: 4.3.0


 Increase the RAM size to 256 for router system vm(Internal load balancer vm 
 also) service offering because 128MB will have very poor performance. Minimum 
 should be 256. Simply because all pointers/data structures are now 64-bit



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-6075) Increase the ram size for router service offering


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901254#comment-13901254
 ] 

Harikrishna Patnala commented on CLOUDSTACK-6075:
-


Patch ready to review @ https://reviews.apache.org/r/17941/

 Increase the ram size for router service offering 
 --

 Key: CLOUDSTACK-6075
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6075
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: Harikrishna Patnala
Assignee: Harikrishna Patnala
 Fix For: 4.3.0


 Increase the RAM size to 256 for router system vm(Internal load balancer vm 
 also) service offering because 128MB will have very poor performance. Minimum 
 should be 256. Simply because all pointers/data structures are now 64-bit



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-6032) [VmScaleup]service offering id is not getting changed in usage_vm_instance table under usage_type 1


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Harikrishna Patnala updated CLOUDSTACK-6032:


Status: Reviewable  (was: In Progress)

 [VmScaleup]service offering id is not getting changed in usage_vm_instance 
 table under usage_type 1 
 

 Key: CLOUDSTACK-6032
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6032
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Usage
Affects Versions: 4.3.0
Reporter: Harikrishna Patnala
Assignee: Harikrishna Patnala
 Fix For: 4.3.0, 4.4.0


 steps to reproduce
 ===
 1-Deploy vm with co small instance{cpu:512,ram=512} 
 2-scaleup vm to co medium instance{cpu:1GHz,ram=1024}
 3-check usage_vm_instance table in usage db
 expected
 =
 for usage_typ 1 and 2 service offerings_id should get update to new SO 
 Actual
 ===
 Sservice_offering_id  is getting updated for usage_type 2 only 
 Detail
 ==
 mysql select * from usage_vm_instance where vm_instance_id=3 and end_date is 
  NULL;
 ++-+++-+-+-+-+-+--+---+---++
 | usage_type | zone_id | account_id | vm_instance_id | vm_name | 
 service_offering_id | template_id | hypervisor_type | start_date  | 
 end_date | cpu_speed | cpu_cores | memory |
 ++-+++-+-+-+-+-+--+---+---++
 |  1 |   1 |  2 |  3 | one |  
 15 |   7 | VMware  | 2014-01-29 14:45:12 | NULL | 
  NULL |  NULL |   NULL |
 |  2 |   1 |  2 |  3 | one |  
  2 |   7 | VMware  | 2014-01-29 14:46:26 | NULL | 
  NULL |  NULL |   NULL |
 ++-+++-+-+-+-+-+--+---+---++



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-6032) [VmScaleup]service offering id is not getting changed in usage_vm_instance table under usage_type 1

2014-02-14 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901255#comment-13901255
 ] 

Harikrishna Patnala commented on CLOUDSTACK-6032:
-

Patch ready to review @https://reviews.apache.org/r/17799/

 [VmScaleup]service offering id is not getting changed in usage_vm_instance 
 table under usage_type 1 
 

 Key: CLOUDSTACK-6032
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6032
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Usage
Affects Versions: 4.3.0
Reporter: Harikrishna Patnala
Assignee: Harikrishna Patnala
 Fix For: 4.3.0, 4.4.0


 steps to reproduce
 ===
 1-Deploy vm with co small instance{cpu:512,ram=512} 
 2-scaleup vm to co medium instance{cpu:1GHz,ram=1024}
 3-check usage_vm_instance table in usage db
 expected
 =
 for usage_typ 1 and 2 service offerings_id should get update to new SO 
 Actual
 ===
 Sservice_offering_id  is getting updated for usage_type 2 only 
 Detail
 ==
 mysql select * from usage_vm_instance where vm_instance_id=3 and end_date is 
  NULL;
 ++-+++-+-+-+-+-+--+---+---++
 | usage_type | zone_id | account_id | vm_instance_id | vm_name | 
 service_offering_id | template_id | hypervisor_type | start_date  | 
 end_date | cpu_speed | cpu_cores | memory |
 ++-+++-+-+-+-+-+--+---+---++
 |  1 |   1 |  2 |  3 | one |  
 15 |   7 | VMware  | 2014-01-29 14:45:12 | NULL | 
  NULL |  NULL |   NULL |
 |  2 |   1 |  2 |  3 | one |  
  2 |   7 | VMware  | 2014-01-29 14:46:26 | NULL | 
  NULL |  NULL |   NULL |
 ++-+++-+-+-+-+-+--+---+---++



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5674) [Automation]: Enhancements to accommodate multiple regression runs on a single CS server

[
https://issues.apache.org/jira/browse/CLOUDSTACK-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901258#comment-13901258
]

ASF subversion and git services commented on CLOUDSTACK-5674:
-

Commit aa2831231cb82773dcf4460a9b29985782d90ebe in branch refs/heads/marvin
from [~gpshilamkar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aa28312 ]

CLOUDSTACK-5674: apiclient was used before it was created. Fixed it.

[Automation]: Enhancements to accommodate multiple regression runs on a
single CS server

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5674) [Automation]: Enhancements to accommodate multiple regression runs on a single CS server

2014-02-14 Thread ASF subversion and git services (JIRA)

[
https://issues.apache.org/jira/browse/CLOUDSTACK-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901267#comment-13901267
]

ASF subversion and git services commented on CLOUDSTACK-5674:
-

Commit 2d93d83b44927e0ede7c0a5440bf5f472cc8d11a in branch refs/heads/marvin
from [~gpshilamkar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2d93d83 ]

CLOUDSTACK-5674: Added missing import for FAILED

[Automation]: Enhancements to accommodate multiple regression runs on a
single CS server

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5674) [Automation]: Enhancements to accommodate multiple regression runs on a single CS server

2014-02-14 Thread ASF subversion and git services (JIRA)

[
https://issues.apache.org/jira/browse/CLOUDSTACK-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901268#comment-13901268
]

ASF subversion and git services commented on CLOUDSTACK-5674:
-

Commit 1eb98e135b0bdd6a00f10c5bbf98e2947334a31d in branch refs/heads/marvin
from [~gpshilamkar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1eb98e1 ]

CLOUDSTACK-5674: Fix a missing closing bracket.

[Automation]: Enhancements to accommodate multiple regression runs on a
single CS server

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6107) [Automation] : test_vpc_vm_life_cycle.py fails with error as AssertionError: VM state should be running after deployment

Dhananjay D Pathak created CLOUDSTACK-6107:
--

 Summary: [Automation] : test_vpc_vm_life_cycle.py fails with error 
as AssertionError: VM state should be running after deployment
 Key: CLOUDSTACK-6107
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6107
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: marvin
Affects Versions: 4.2.0
 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server 
release 6.4 (Santiago) 
Reporter: Dhananjay D Pathak


Marvin Test test_vpc_vm_life_cycle.py fails with Error as described bellow (log 
files are attached):


Test deploy virtual machine in two isolated networks ... ok
Test deploy virtual machine when VPC VR in stopped state ... FAIL
ERROR
ERROR
Test deploy an instance in VPC networks ... FAIL
Test stop an instance in VPC networks ... ok
Test start an instance in VPC networks ... FAIL
Test reboot an instance in VPC networks ... FAIL
Test destroy an instance in VPC networks ... FAIL
Test recover an instance in VPC networks ... FAIL
Test migrate an instance in VPC networks ... FAIL
Test user data in virtual machines ... FAIL
Test meta data in virtual machines ... FAIL
Test expunge an instance in VPC networks ... FAIL
Test deploy an instance in VPC networks ... FAIL
Test stop an instance in VPC networks ... ok
Test start an instance in VPC networks ... FAIL
Test reboot an instance in VPC networks ... FAIL
Test destroy an instance in VPC networks ... FAIL
Test recover an instance in VPC networks ... FAIL
Test migrate an instance in VPC networks ... FAIL
Test user data in virtual machines ... FAIL
Test meta data in virtual machines ... FAIL
Test expunge an instance in VPC networks ... FAIL

==
ERROR: test suite for class 
'integration.component.test_vpc_vm_life_cycle.TestVMLifeCycleDiffHosts'
--
Traceback (most recent call last):
  File 
/usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/suite.py, 
line 208, in run
self.setUp()
  File 
/usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/suite.py, 
line 291, in setUp
self.setupContext(ancestor)
  File 
/usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/suite.py, 
line 314, in setupContext
try_run(context, names)
  File 
/usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/util.py, 
line 469, in try_run
return func()
  File 
/DataDisk/temp/cloudstack/test/integration/component/test_vpc_vm_life_cycle.py,
 line 2952, in setUpClass
raise Exception(Warning: Exception during setup : %s % e)
Exception: Warning: Exception during setup : Execute cmd: asyncquery failed, 
due to: {errorcode : 533, errortext : u'Unable to create a deployment for 
VM[User|9d35132b-10ba-4a40-b313-72cd40fac3ea]'}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-6107) [Automation] : test_vpc_vm_life_cycle.py fails with error as AssertionError: VM state should be running after deployment

[
https://issues.apache.org/jira/browse/CLOUDSTACK-6107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dhananjay D Pathak updated CLOUDSTACK-6107:
---

Attachment: runinfo.txt
results.txt
failed_plus_exceptions.txt

Log files for execution of test_vpc_vm_life_cycle.py are attached.

[Automation] : test_vpc_vm_life_cycle.py fails with error as AssertionError:
VM state should be running after deployment

Key: CLOUDSTACK-6107
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6107
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: marvin
Affects Versions: 4.2.0
Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server
release 6.4 (Santiago)
Reporter: Dhananjay D Pathak
Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt

Marvin Test test_vpc_vm_life_cycle.py fails with Error as described bellow
(log files are attached):
Test deploy virtual machine in two isolated networks ... ok
Test deploy virtual machine when VPC VR in stopped state ... FAIL
ERROR
ERROR
Test deploy an instance in VPC networks ... FAIL
Test stop an instance in VPC networks ... ok
Test start an instance in VPC networks ... FAIL
Test reboot an instance in VPC networks ... FAIL
Test destroy an instance in VPC networks ... FAIL
Test recover an instance in VPC networks ... FAIL
Test migrate an instance in VPC networks ... FAIL
Test user data in virtual machines ... FAIL
Test meta data in virtual machines ... FAIL
Test expunge an instance in VPC networks ... FAIL
Test deploy an instance in VPC networks ... FAIL
Test stop an instance in VPC networks ... ok
Test start an instance in VPC networks ... FAIL
Test reboot an instance in VPC networks ... FAIL
Test destroy an instance in VPC networks ... FAIL
Test recover an instance in VPC networks ... FAIL
Test migrate an instance in VPC networks ... FAIL
Test user data in virtual machines ... FAIL
Test meta data in virtual machines ... FAIL
Test expunge an instance in VPC networks ... FAIL
==
ERROR: test suite for class
'integration.component.test_vpc_vm_life_cycle.TestVMLifeCycleDiffHosts'
--
Traceback (most recent call last):
File
/usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/suite.py,
line 208, in run
self.setUp()
File
/usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/suite.py,
line 291, in setUp
self.setupContext(ancestor)
File
/usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/suite.py,
line 314, in setupContext
try_run(context, names)
File
/usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/util.py,
line 469, in try_run
return func()
File
/DataDisk/temp/cloudstack/test/integration/component/test_vpc_vm_life_cycle.py,
line 2952, in setUpClass
raise Exception(Warning: Exception during setup : %s % e)
Exception: Warning: Exception during setup : Execute cmd: asyncquery failed,
due to: {errorcode : 533, errortext : u'Unable to create a deployment for
VM[User|9d35132b-10ba-4a40-b313-72cd40fac3ea]'}

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6108) Network throttling for the VM's running on Hyper-V

2014-02-14 Thread Rajesh Battala (JIRA)

Rajesh Battala created CLOUDSTACK-6108:
--

 Summary: Network throttling for the VM's running on Hyper-V
 Key: CLOUDSTACK-6108
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6108
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Hypervisor Controller
Affects Versions: 4.4.0
Reporter: Rajesh Battala
Assignee: Rajesh Battala
 Fix For: 4.4.0






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6109) Support of iSCSI as primary store in Hyper-V

2014-02-14 Thread Rajesh Battala (JIRA)

Rajesh Battala created CLOUDSTACK-6109:
--

 Summary: Support of iSCSI as primary store in Hyper-V
 Key: CLOUDSTACK-6109
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6109
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Hypervisor Controller
Affects Versions: 4.4.0
Reporter: Rajesh Battala
Assignee: Rajesh Battala
 Fix For: 4.4.0






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6110) [Automation] : test_vmware_drs.py fails with errorText:Maximum number of resources of type 'memory' for account nameIdentifierin domain id=1 has been exceeded.

Dhananjay D Pathak created CLOUDSTACK-6110:
--

 Summary: [Automation] : test_vmware_drs.py fails with 
errorText:Maximum number of resources of type 'memory' for account 
nameIdentifierin domain id=1 has been exceeded.
 Key: CLOUDSTACK-6110
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6110
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: marvin
Affects Versions: 4.2.0
 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server 
release 6.4 (Santiago) 
Reporter: Dhananjay D Pathak


Test Set up affinity rules ... SKIP: Skipping...Host Affinity feature not 
available yet in cloudstack
Test Set up anti-affinity rules ... SKIP: Skipping... Not tested due to 
unavailibility of multihosts setup - 3 hosts in a cluster
Test VM Creation in  automation mode = Fully automated ... ERROR

==
ERROR: Test VM Creation in  automation mode = Fully automated
--
Traceback (most recent call last):
  File 
/DataDisk/temp/cloudstack/test/integration/component/test_vmware_drs.py, line 
229, in test_vm_creation_in_fully_automated_mode
hostid = host_1.id
  File /usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, 
line 415, in create
virtual_machine = apiclient.deployVirtualMachine(cmd, method=method)
  File 
/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
 line 593, in deployVirtualMachine
response = self.connection.marvinRequest(command, response_type=response, 
method=method)
  File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, 
line 272, in marvinRequest
response = jsonHelper.getResultObj(response.json(), response_type)
  File /usr/local/lib/python2.7/site-packages/marvin/jsonHelper.py, line 148, 
in getResultObj
raise cloudstackException.cloudstackAPIException(respname, errMsg)
cloudstackAPIException: Execute cmd: deployvirtualmachine failed, due to: 
errorCode: 535, errorText:Maximum number of resources of type 'memory' for 
account 
name=test-TestVMPlacement-test_vm_creation_in_fully_automated_mode-BZUWO8 in 
domain id=1 has been exceeded.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-6110) [Automation] : test_vmware_drs.py fails with errorText:Maximum number of resources of type 'memory' for account nameIdentifierin domain id=1 has been exceeded.


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dhananjay D Pathak updated CLOUDSTACK-6110:
---

Attachment: runinfo.txt
results.txt
failed_plus_exceptions.txt

Log files for execution of test_vmware_drs.py are attached.


 [Automation] : test_vmware_drs.py fails with errorText:Maximum number of 
 resources of type 'memory' for account nameIdentifierin domain id=1 has 
 been exceeded.
 -

 Key: CLOUDSTACK-6110
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6110
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: marvin
Affects Versions: 4.2.0
 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server 
 release 6.4 (Santiago) 
Reporter: Dhananjay D Pathak
 Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt


 Test Set up affinity rules ... SKIP: Skipping...Host Affinity feature not 
 available yet in cloudstack
 Test Set up anti-affinity rules ... SKIP: Skipping... Not tested due to 
 unavailibility of multihosts setup - 3 hosts in a cluster
 Test VM Creation in  automation mode = Fully automated ... ERROR
 ==
 ERROR: Test VM Creation in  automation mode = Fully automated
 --
 Traceback (most recent call last):
   File 
 /DataDisk/temp/cloudstack/test/integration/component/test_vmware_drs.py, 
 line 229, in test_vm_creation_in_fully_automated_mode
 hostid = host_1.id
   File 
 /usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, line 
 415, in create
 virtual_machine = apiclient.deployVirtualMachine(cmd, method=method)
   File 
 /usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
  line 593, in deployVirtualMachine
 response = self.connection.marvinRequest(command, response_type=response, 
 method=method)
   File 
 /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 
 272, in marvinRequest
 response = jsonHelper.getResultObj(response.json(), response_type)
   File /usr/local/lib/python2.7/site-packages/marvin/jsonHelper.py, line 
 148, in getResultObj
 raise cloudstackException.cloudstackAPIException(respname, errMsg)
 cloudstackAPIException: Execute cmd: deployvirtualmachine failed, due to: 
 errorCode: 535, errorText:Maximum number of resources of type 'memory' for 
 account 
 name=test-TestVMPlacement-test_vm_creation_in_fully_automated_mode-BZUWO8 in 
 domain id=1 has been exceeded.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6111) [Automation] : test_redundant_router_upgrades.py fails with error as AssertionError: List network offering should not return empty response

Dhananjay D Pathak created CLOUDSTACK-6111:
--

 Summary: [Automation] : test_redundant_router_upgrades.py fails 
with error as AssertionError: List network offering should not return empty 
response
 Key: CLOUDSTACK-6111
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6111
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: marvin
Affects Versions: 4.2.0
 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server 
release 6.4 (Santiago) 
Reporter: Dhananjay D Pathak


Marvin Test test_redundant_router_upgrades.py fails with Error as described 
bellow (log files are attached):
Test downgrade redundant virtual router to virtual router ... FAIL
Test upgrade virtual router to redundant virtual router ... FAIL

==
FAIL: Test downgrade redundant virtual router to virtual router
--
Traceback (most recent call last):
  File 
/DataDisk/temp/cloudstack/test/integration/component/test_redundant_router_upgrades.py,
 line 464, in test_downgradeRvR_to_VR
List network offering should not return empty response
AssertionError: List network offering should not return empty response



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6112) Adding VPC router to a guest network fails with StringIndexOutOfBoundsException

2014-02-14 Thread Likitha Shetty (JIRA)

Likitha Shetty created CLOUDSTACK-6112:
--

 Summary: Adding VPC router to a guest network fails with 
StringIndexOutOfBoundsException
 Key: CLOUDSTACK-6112
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6112
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: VMware
Affects Versions: 4.4.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
 Fix For: 4.4.0


Steps to reproduce
Step 1: Create advanced zone in vmware
Step 2: Create a VPC
Step 3: Create a tier in VPC
Step 3: Deploy an instance in the tier

Result
Addition of the VPC router to the tier fails with 
StringIndexOutOfBoundsException

2014-02-13 16:30:27,762 DEBUG [c.c.a.t.Request] (DirectAgent-220:ctx-90db2216) 
Seq 1-1024328360: Executing: { Cmd , MgmtId: 9092810
6758026, via: 1(10.223.250.131), Ver: v1, Flags: 100111, 
[{com.cloud.agent.api.SetupGuestNetworkCommand:{dhcpRange:10.1.1.1,n
etworkDomain:vpc.networkacl,isRedundant:false,add:false,nic:
{deviceId:2,networkRateMbps:200,defaultNic:false,uuid: 
1a9263c1-81d0-4029-8078-e5b82f826c46,ip:10.1.1.1,netmask:255.255.255.192,gateway:10.1.1.1,mac:02:00:6e:67:00:02,br
 
oadcastType:Vlan,type:Guest,broadcastUri:vlan://3181,isolationUri:vlan://3181,isSecurityGroupEnabled:false}
,access
Details:
{router.guest.ip:10.1.1.1,guest.vlan.tag:3181,guest.network.gateway:10.1.1.1,guest.bridge:10.1.1.63,router
 .name:r-42-TestVM,router.ip:10.223.250.177}
,wait:0}}] }
2014-02-13 16:30:27,762 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-351:ctx-478d4018) Seq 1-1024328360: Executing request
2014-02-13 16:30:27,763 INFO [c.c.h.v.r.VmwareResource] 
(DirectAgent-351:ctx-478d4018 10.223.250.131) Executing resource SetupGuest
NetworkCommand 
{dhcpRange:10.1.1.1,networkDomain:vpc.networkacl,isRedundant:false,add:false,nic:
{deviceId:2,network 
RateMbps:200,defaultNic:false,uuid:1a9263c1-81d0-4029-8078-e5b82f826c46,ip:10.1.1.1,netmask:255.255.255.192,gateway
 
:10.1.1.1,mac:02:00:6e:67:00:02,broadcastType:Vlan,type:Guest,broadcastUri:vlan://3181,isolationUri:vlan://3181
 ,isSecurityGroupEnabled:false}
,accessDetails:
{router.guest.ip:10.1.1.1,guest.vlan.tag:3181,guest.network.gateway:10.
 
1.1.1,guest.bridge:10.1.1.63,router.name:r-42-TestVM,router.ip:10.223.250.177}
,wait:0}
2014-02-13 16:30:27,770 WARN [o.a.c.e.o.NetworkOrchestrator] 
(Job-Executor-13:ctx-ee224891 ctx-d13e90ae) Unable to complete shutdown of the 
network elements due to element: VpcVirtualRouter
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:762)
at java.lang.StringBuffer.deleteCharAt(StringBuffer.java:378)
at com.cloud.hypervisor.guru.VMwareGuru.implement(VMwareGuru.java:279)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveVmFromNetwork(VirtualMachineManagerImpl.java:3546)
at 
com.cloud.vm.VirtualMachineManagerImpl.removeVmFromNetwork(VirtualMachineManagerImpl.java:3531)
at 
com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.removeVpcRouterFromGuestNetwork(VpcVirtualNetworkApplianceManagerImpl.java:319)
at sun.reflect.GeneratedMethodAccessor537.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
ManagerImpl.java:319)
at sun.reflect.GeneratedMethodAccessor537.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy196.removeVpcRouterFromGuestNetwork(Unknown Source)
at 
com.cloud.network.element.VpcVirtualRouterElement.shutdown(VpcVirtualRouterElement.java:261)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.shutdownNetworkElementsAndResources(NetworkOrchestrator.java:2052)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.shutdownNetwork(NetworkOrchestrator.java:1965)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetwork(NetworkOrchestrator.java:989)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1221)
at

[jira] [Updated] (CLOUDSTACK-6095) [Automation] : test_vpc_network_pfrules.pyfails with error as AssertionError: Failed to SSH into VM


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dhananjay D Pathak updated CLOUDSTACK-6095:
---

Attachment: runinfo.txt
results.txt
failed_plus_exceptions.txt

Similar issue is observed for other test test_shared_networks too, so updating 
here.
Log files for execution of test_shared_networks.py are attached.


 [Automation] : test_vpc_network_pfrules.pyfails with error as AssertionError: 
 Failed to SSH into VM 
 

 Key: CLOUDSTACK-6095
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6095
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: marvin
Affects Versions: 4.2.0
 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server 
 release 6.4 (Santiago) 
Reporter: Dhananjay D Pathak
 Attachments: failed_plus_exceptions.txt, failed_plus_exceptions.txt, 
 failed_plus_exceptions.txt, index.html, results.txt, results.txt, 
 results.txt, runinfo.txt, runinfo.txt, runinfo.txt


 Marvin Test test_vpc_network_pfrules.py fails with Error as described bellow 
 (log files are attached):
 Test : Create VPC PF rules on acquired public ip when VpcVirtualRouter is 
 stopped ... FAIL
 Test Create VPC PF rules on acquired public ip when VpcVirtualRouter is 
 Running ... FAIL
 Test Create multiple VPC PF rules on acquired public ip in diff't networks 
 when VpcVirtualRouter is stopped ... FAIL
 Test Create multiple VPC PF rules on acquired public ip in diff't networks 
 when VpcVirtualRouter is running ... FAIL
 Test delete a PF rule in VPC when VpcVirtualRouter is Stopped ... FAIL
 Test delete a PF rule in VPC when VpcVirtualRouter is Running ... FAIL
 Test delete all PF rules in VPC when VpcVirtualRouter is Stopped ... FAIL
 Test delete all PF rules in VPC when VpcVirtualRouter is Running ... FAIL
 Test delete all PF rules in VPC across multiple networks when 
 VpcVirtualRouter is Stopped ... FAIL
 Test delete all PF rules in VPC across multiple networks when 
 VpcVirtualRouter is Running ... FAIL
 ==
 FAIL: Test : Create VPC PF rules on acquired public ip when VpcVirtualRouter 
 is stopped
 --
 Traceback (most recent call last):
   File 
 /DataDisk/temp/cloudstack/test/integration/component/test_vpc_network_pfrules.py,
  line 508, in test_01_network_services_VPC_StopCreatePF
 self.check_ssh_into_vm(vm_1, public_ip_1, testnegative=False)
   File 
 /DataDisk/temp/cloudstack/test/integration/component/test_vpc_network_pfrules.py,
  line 328, in check_ssh_into_vm
 self.fail(Failed to SSH into VM - %s % (public_ip.ipaddress.ipaddress))
 AssertionError: Failed to SSH into VM - 207.19.99.48



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-6111) [Automation] : test_redundant_router_upgrades.py fails with error as AssertionError: List network offering should not return empty response


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dhananjay D Pathak updated CLOUDSTACK-6111:
---

Attachment: runinfo.txt
results.txt
failed_plus_exceptions.txt

Log files for execution of test_redundant_router_upgrades.py are attached.


 [Automation] : test_redundant_router_upgrades.py fails with error as 
 AssertionError: List network offering should not return empty response
 ---

 Key: CLOUDSTACK-6111
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6111
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: marvin
Affects Versions: 4.2.0
 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server 
 release 6.4 (Santiago) 
Reporter: Dhananjay D Pathak
 Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt


 Marvin Test test_redundant_router_upgrades.py fails with Error as described 
 bellow (log files are attached):
 Test downgrade redundant virtual router to virtual router ... FAIL
 Test upgrade virtual router to redundant virtual router ... FAIL
 ==
 FAIL: Test downgrade redundant virtual router to virtual router
 --
 Traceback (most recent call last):
   File 
 /DataDisk/temp/cloudstack/test/integration/component/test_redundant_router_upgrades.py,
  line 464, in test_downgradeRvR_to_VR
 List network offering should not return empty response
 AssertionError: List network offering should not return empty response



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6113) [Automation] : test_advancedsg_networks.py fails with error as TypeError: 'NoneType' object has no attribute 'getitem'

Dhananjay D Pathak created CLOUDSTACK-6113:
--

 Summary: [Automation] : test_advancedsg_networks.py fails with 
error as TypeError: 'NoneType' object has no attribute '__getitem__'
 Key: CLOUDSTACK-6113
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6113
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: marvin
Affects Versions: 4.2.0
 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server 
release 6.4 (Santiago) 

Reporter: Dhananjay D Pathak


Marvin Test test_advancedsg_networks.py fails with Error as described bellow 
(log files are attached):


ERROR
Test to verify Advance Zone with security group enabled can be created ... ERROR
Test to verify Advance Zone created with flag ... ERROR
ERROR
ERROR
ERROR
ERROR

==
ERROR: test suite for class 
'integration.component.test_advancedsg_networks.TestAccountBasedIngressRules'
--
Traceback (most recent call last):
  File 
/usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/suite.py, 
line 208, in run
self.setUp()
  File 
/usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/suite.py, 
line 291, in setUp
self.setupContext(ancestor)
  File 
/usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/suite.py, 
line 314, in setupContext
try_run(context, names)
  File 
/usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/util.py, 
line 469, in try_run
return func()
  File 
/DataDisk/temp/cloudstack/test/integration/component/test_advancedsg_networks.py,
 line 2826, in setUpClass
cls.template = 
get_template(cls.api_client,cls.zone.id,cls.services[ostype])
TypeError: 'NoneType' object has no attribute '__getitem__'



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-6113) [Automation] : test_advancedsg_networks.py fails with error as TypeError: 'NoneType' object has no attribute 'getitem'

2014-02-14 Thread ASF subversion and git services (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dhananjay D Pathak updated CLOUDSTACK-6113:
---

Attachment: runinfo.txt
results.txt
failed_plus_exceptions.txt

Log files for execution of test_advancedsg_networks.py are attached.


 [Automation] : test_advancedsg_networks.py fails with error as TypeError: 
 'NoneType' object has no attribute '__getitem__'
 --

 Key: CLOUDSTACK-6113
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6113
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: marvin
Affects Versions: 4.2.0
 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server 
 release 6.4 (Santiago) 
Reporter: Dhananjay D Pathak
 Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt


 Marvin Test test_advancedsg_networks.py fails with Error as described bellow 
 (log files are attached):
 ERROR
 Test to verify Advance Zone with security group enabled can be created ... 
 ERROR
 Test to verify Advance Zone created with flag ... ERROR
 ERROR
 ERROR
 ERROR
 ERROR
 ==
 ERROR: test suite for class 
 'integration.component.test_advancedsg_networks.TestAccountBasedIngressRules'
 --
 Traceback (most recent call last):
   File 
 /usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/suite.py, 
 line 208, in run
 self.setUp()
   File 
 /usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/suite.py, 
 line 291, in setUp
 self.setupContext(ancestor)
   File 
 /usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/suite.py, 
 line 314, in setupContext
 try_run(context, names)
   File 
 /usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg/nose/util.py, 
 line 469, in try_run
 return func()
   File 
 /DataDisk/temp/cloudstack/test/integration/component/test_advancedsg_networks.py,
  line 2826, in setUpClass
 cls.template = 
 get_template(cls.api_client,cls.zone.id,cls.services[ostype])
 TypeError: 'NoneType' object has no attribute '__getitem__'



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-6112) Adding VPC router to a guest network fails with StringIndexOutOfBoundsException


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901362#comment-13901362
 ] 

ASF subversion and git services commented on CLOUDSTACK-6112:
-

Commit db91e54bf3c079e6b9932258f6327585f11cac08 in branch refs/heads/master 
from [~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=db91e54 ]

CLOUDSTACK-6112. Adding VPC router to a guest network fails with 
StringIndexOutOfBoundsException.


 Adding VPC router to a guest network fails with 
 StringIndexOutOfBoundsException
 ---

 Key: CLOUDSTACK-6112
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6112
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VMware
Affects Versions: 4.4.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
 Fix For: 4.4.0


 Steps to reproduce
 Step 1: Create advanced zone in vmware
 Step 2: Create a VPC
 Step 3: Create a tier in VPC
 Step 3: Deploy an instance in the tier
 Result
 Addition of the VPC router to the tier fails with 
 StringIndexOutOfBoundsException
 2014-02-13 16:30:27,762 DEBUG [c.c.a.t.Request] 
 (DirectAgent-220:ctx-90db2216) Seq 1-1024328360: Executing: { Cmd , MgmtId: 
 9092810
 6758026, via: 1(10.223.250.131), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.SetupGuestNetworkCommand:{dhcpRange:10.1.1.1,n
 etworkDomain:vpc.networkacl,isRedundant:false,add:false,nic:
 {deviceId:2,networkRateMbps:200,defaultNic:false,uuid: 
 1a9263c1-81d0-4029-8078-e5b82f826c46,ip:10.1.1.1,netmask:255.255.255.192,gateway:10.1.1.1,mac:02:00:6e:67:00:02,br
  
 oadcastType:Vlan,type:Guest,broadcastUri:vlan://3181,isolationUri:vlan://3181,isSecurityGroupEnabled:false}
 ,access
 Details:
 {router.guest.ip:10.1.1.1,guest.vlan.tag:3181,guest.network.gateway:10.1.1.1,guest.bridge:10.1.1.63,router
  .name:r-42-TestVM,router.ip:10.223.250.177}
 ,wait:0}}] }
 2014-02-13 16:30:27,762 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-351:ctx-478d4018) Seq 1-1024328360: Executing request
 2014-02-13 16:30:27,763 INFO [c.c.h.v.r.VmwareResource] 
 (DirectAgent-351:ctx-478d4018 10.223.250.131) Executing resource SetupGuest
 NetworkCommand 
 {dhcpRange:10.1.1.1,networkDomain:vpc.networkacl,isRedundant:false,add:false,nic:
 {deviceId:2,network 
 RateMbps:200,defaultNic:false,uuid:1a9263c1-81d0-4029-8078-e5b82f826c46,ip:10.1.1.1,netmask:255.255.255.192,gateway
  
 :10.1.1.1,mac:02:00:6e:67:00:02,broadcastType:Vlan,type:Guest,broadcastUri:vlan://3181,isolationUri:vlan://3181
  ,isSecurityGroupEnabled:false}
 ,accessDetails:
 {router.guest.ip:10.1.1.1,guest.vlan.tag:3181,guest.network.gateway:10.
  
 1.1.1,guest.bridge:10.1.1.63,router.name:r-42-TestVM,router.ip:10.223.250.177}
 ,wait:0}
 2014-02-13 16:30:27,770 WARN [o.a.c.e.o.NetworkOrchestrator] 
 (Job-Executor-13:ctx-ee224891 ctx-d13e90ae) Unable to complete shutdown of 
 the network elements due to element: VpcVirtualRouter
 java.lang.StringIndexOutOfBoundsException: String index out of range: -1
 at 
 java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:762)
 at java.lang.StringBuffer.deleteCharAt(StringBuffer.java:378)
 at com.cloud.hypervisor.guru.VMwareGuru.implement(VMwareGuru.java:279)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveVmFromNetwork(VirtualMachineManagerImpl.java:3546)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.removeVmFromNetwork(VirtualMachineManagerImpl.java:3531)
 at 
 com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.removeVpcRouterFromGuestNetwork(VpcVirtualNetworkApplianceManagerImpl.java:319)
 at sun.reflect.GeneratedMethodAccessor537.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ManagerImpl.java:319)
 at sun.reflect.GeneratedMethodAccessor537.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at com.sun.proxy.$Proxy196.removeVpcRouterFromGuestNetwork(Unknown

[jira] [Resolved] (CLOUDSTACK-6112) Adding VPC router to a guest network fails with StringIndexOutOfBoundsException

2014-02-14 Thread Likitha Shetty (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Likitha Shetty resolved CLOUDSTACK-6112.


Resolution: Fixed

 Adding VPC router to a guest network fails with 
 StringIndexOutOfBoundsException
 ---

 Key: CLOUDSTACK-6112
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6112
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VMware
Affects Versions: 4.4.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
 Fix For: 4.4.0


 Steps to reproduce
 Step 1: Create advanced zone in vmware
 Step 2: Create a VPC
 Step 3: Create a tier in VPC
 Step 3: Deploy an instance in the tier
 Result
 Addition of the VPC router to the tier fails with 
 StringIndexOutOfBoundsException
 2014-02-13 16:30:27,762 DEBUG [c.c.a.t.Request] 
 (DirectAgent-220:ctx-90db2216) Seq 1-1024328360: Executing: { Cmd , MgmtId: 
 9092810
 6758026, via: 1(10.223.250.131), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.SetupGuestNetworkCommand:{dhcpRange:10.1.1.1,n
 etworkDomain:vpc.networkacl,isRedundant:false,add:false,nic:
 {deviceId:2,networkRateMbps:200,defaultNic:false,uuid: 
 1a9263c1-81d0-4029-8078-e5b82f826c46,ip:10.1.1.1,netmask:255.255.255.192,gateway:10.1.1.1,mac:02:00:6e:67:00:02,br
  
 oadcastType:Vlan,type:Guest,broadcastUri:vlan://3181,isolationUri:vlan://3181,isSecurityGroupEnabled:false}
 ,access
 Details:
 {router.guest.ip:10.1.1.1,guest.vlan.tag:3181,guest.network.gateway:10.1.1.1,guest.bridge:10.1.1.63,router
  .name:r-42-TestVM,router.ip:10.223.250.177}
 ,wait:0}}] }
 2014-02-13 16:30:27,762 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-351:ctx-478d4018) Seq 1-1024328360: Executing request
 2014-02-13 16:30:27,763 INFO [c.c.h.v.r.VmwareResource] 
 (DirectAgent-351:ctx-478d4018 10.223.250.131) Executing resource SetupGuest
 NetworkCommand 
 {dhcpRange:10.1.1.1,networkDomain:vpc.networkacl,isRedundant:false,add:false,nic:
 {deviceId:2,network 
 RateMbps:200,defaultNic:false,uuid:1a9263c1-81d0-4029-8078-e5b82f826c46,ip:10.1.1.1,netmask:255.255.255.192,gateway
  
 :10.1.1.1,mac:02:00:6e:67:00:02,broadcastType:Vlan,type:Guest,broadcastUri:vlan://3181,isolationUri:vlan://3181
  ,isSecurityGroupEnabled:false}
 ,accessDetails:
 {router.guest.ip:10.1.1.1,guest.vlan.tag:3181,guest.network.gateway:10.
  
 1.1.1,guest.bridge:10.1.1.63,router.name:r-42-TestVM,router.ip:10.223.250.177}
 ,wait:0}
 2014-02-13 16:30:27,770 WARN [o.a.c.e.o.NetworkOrchestrator] 
 (Job-Executor-13:ctx-ee224891 ctx-d13e90ae) Unable to complete shutdown of 
 the network elements due to element: VpcVirtualRouter
 java.lang.StringIndexOutOfBoundsException: String index out of range: -1
 at 
 java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:762)
 at java.lang.StringBuffer.deleteCharAt(StringBuffer.java:378)
 at com.cloud.hypervisor.guru.VMwareGuru.implement(VMwareGuru.java:279)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveVmFromNetwork(VirtualMachineManagerImpl.java:3546)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.removeVmFromNetwork(VirtualMachineManagerImpl.java:3531)
 at 
 com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.removeVpcRouterFromGuestNetwork(VpcVirtualNetworkApplianceManagerImpl.java:319)
 at sun.reflect.GeneratedMethodAccessor537.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ManagerImpl.java:319)
 at sun.reflect.GeneratedMethodAccessor537.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at com.sun.proxy.$Proxy196.removeVpcRouterFromGuestNetwork(Unknown Source)
 at 
 com.cloud.network.element.VpcVirtualRouterElement.shutdown(VpcVirtualRouterElement.java:261)
 at 
 org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.shutdownNetworkElementsAndResources(NetworkOrchestrator.java:2052)
 at

[jira] [Commented] (CLOUDSTACK-6054) [Hyper-v] vmsync is not working for hyperv

2014-02-14 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901394#comment-13901394
 ] 

ASF subversion and git services commented on CLOUDSTACK-6054:
-

Commit ccc168c7044017ce8916cff923b9b18fbb18088c in branch 
refs/heads/4.3-forward from [~rajesh_battala]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ccc168c ]

Revert CLOUDSTACK-6054: Changes for making vmsync work for hyper-v. Made 
changes to PingCommand and

This reverts commit eef65ac776de171d83f9f532ac2dda6902117178.
This commit should not be in 4.3-forward and its already present in master


 [Hyper-v] vmsync is not working for hyperv
 --

 Key: CLOUDSTACK-6054
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6054
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller
Affects Versions: 4.3.0
Reporter: Anshul Gangwar
Assignee: Anshul Gangwar
 Fix For: 4.3.0


 vmsync is not working for hyperv



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6114) Create config management recipes to install CloudStack

2014-02-14 Thread sebastien goasguen (JIRA)

sebastien goasguen created CLOUDSTACK-6114:
--

 Summary: Create config management recipes to install CloudStack
 Key: CLOUDSTACK-6114
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6114
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: sebastien goasguen


To ease deployment of CloudStack we need to develop a set of recipes for all 
the configuration management systems. A few already exists using Chef, Puppet 
and Ansible.

This project will do an inventory of existing recipes available on-line, 
coalesce them into a coherent set and write missing recipes.

The student will need to learn configuration management with at least one tool 
(chef, puppet, ansible, salt..etc) and will develop recipes using Vagrant.

The outcome will be a fully functional devcloud (cloudstack sandbox) with 
mutiple recipes. CloudStack will be deployable in a sanbox or in a 
multi-machine environment.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6115) GSoC: Investigate the use of TravisCI for CloudStack integration testing

2014-02-14 Thread sebastien goasguen (JIRA)

sebastien goasguen created CLOUDSTACK-6115:
--

 Summary: GSoC: Investigate the use of TravisCI for CloudStack 
integration testing
 Key: CLOUDSTACK-6115
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6115
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: sebastien goasguen


Integration testing is currently performed using jenkins and the CloudStack 
simulator.

In this project the student will learn about integration testing and the marvin 
framework in CloudStack (written in Python). The student will also learn about 
TravisCI a system to perform continuous testing and integration testing. 

Using a github mirror, the student will setup Travis builds that will use the 
cloudstack simulator and run the integration tests on each commit.

This is a great project to learn about CI, tests and CloudStack.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-6116) [Automation] : test_cpu_limits.py fails with error as AssertionError: Failed to migrate instance: Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dhananjay D Pathak updated CLOUDSTACK-6116:
---

Attachment: runinfo.txt
results.txt
failed_plus_exceptions.txt

Log files for execution of test_cpu_limits.py are attached.


 [Automation] : test_cpu_limits.py fails with error as AssertionError: Failed 
 to migrate instance: Execute cmd: asyncquery failed, due to: {errorcode : 
 530, errortext : u'Source and destination host are not in same cluster, 
 unable to migrate to host: 1'}
 -

 Key: CLOUDSTACK-6116
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6116
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: marvin
Affects Versions: 4.2.0
 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server 
 release 6.4 (Santiago) 
Reporter: Dhananjay D Pathak
 Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt


 Marvin Test test_cpu_limits.py fails with Error as described bellow (log 
 files are attached):
 Test Deploy VM with multiple core CPU  verify the usage ... ok
 Test Deploy VM with multiple core CPU  verify the usage ... FAIL
 Test Deploy VM with multiple core CPU  verify the usage ... ok
 Test Deploy multiple VM with 4 core CPU  verify the usage ... ok
 Test Deploy VM with 4 core CPU  verify the usage ... ok
 Test Deploy VM with 4 core CPU  verify the usage ... FAIL
 Test Deploy VM with 4 core CPU  verify the usage ... FAIL
 Test Deploy multiple VM with 4 core CPU  verify the usage ... SKIP: This 
 test case requires configuration value max.account.cpus to be 16
 ==
 FAIL: Test Deploy VM with multiple core CPU  verify the usage
 --
 Traceback (most recent call last):
   File 
 /DataDisk/temp/cloudstack/test/integration/component/test_cpu_limits.py, 
 line 261, in test_02_multiplecore_migrate_instance
 self.fail(Failed to migrate instance: %s % e)
 AssertionError: Failed to migrate instance: Execute cmd: asyncquery failed, 
 due to: {errorcode : 530, errortext : u'Source and destination host are not 
 in same cluster, unable to migrate to host: 1'}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6116) [Automation] : test_cpu_limits.py fails with error as AssertionError: Failed to migrate instance: Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext

Dhananjay D Pathak created CLOUDSTACK-6116:
--

 Summary: [Automation] : test_cpu_limits.py fails with error as 
AssertionError: Failed to migrate instance: Execute cmd: asyncquery failed, due 
to: {errorcode : 530, errortext : u'Source and destination host are not in same 
cluster, unable to migrate to host: 1'}
 Key: CLOUDSTACK-6116
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6116
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: marvin
Affects Versions: 4.2.0
 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server 
release 6.4 (Santiago) 

Reporter: Dhananjay D Pathak
 Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt

Marvin Test test_cpu_limits.py fails with Error as described bellow (log files 
are attached):
Test Deploy VM with multiple core CPU  verify the usage ... ok
Test Deploy VM with multiple core CPU  verify the usage ... FAIL
Test Deploy VM with multiple core CPU  verify the usage ... ok
Test Deploy multiple VM with 4 core CPU  verify the usage ... ok
Test Deploy VM with 4 core CPU  verify the usage ... ok
Test Deploy VM with 4 core CPU  verify the usage ... FAIL
Test Deploy VM with 4 core CPU  verify the usage ... FAIL
Test Deploy multiple VM with 4 core CPU  verify the usage ... SKIP: This test 
case requires configuration value max.account.cpus to be 16

==
FAIL: Test Deploy VM with multiple core CPU  verify the usage
--
Traceback (most recent call last):
  File 
/DataDisk/temp/cloudstack/test/integration/component/test_cpu_limits.py, line 
261, in test_02_multiplecore_migrate_instance
self.fail(Failed to migrate instance: %s % e)
AssertionError: Failed to migrate instance: Execute cmd: asyncquery failed, due 
to: {errorcode : 530, errortext : u'Source and destination host are not in same 
cluster, unable to migrate to host: 1'}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-6117) [Automation] : test_implicit_planner.py fails with error as EXCEPTION: test_01_deploy_vm_with_implicit_planner cloudstackAPIException: Execute cmd: asyncquery failed


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dhananjay D Pathak updated CLOUDSTACK-6117:
---

Attachment: runinfo.txt
results.txt
failed_plus_exceptions.txt

Log files for execution of test_implicit_planner.py are attached.


 [Automation] : test_implicit_planner.py fails with error as EXCEPTION: 
 test_01_deploy_vm_with_implicit_planner cloudstackAPIException: Execute cmd: 
 asyncquery failed, due to: Async job timeout deployVirtualMachine Jobid
 -

 Key: CLOUDSTACK-6117
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6117
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: marvin
Affects Versions: 4.2.0
 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server 
 release 6.4 (Santiago) 
Reporter: Dhananjay D Pathak
 Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt


 Marvin Test test_implicit_planner.py fails with Error as described bellow 
 (log files are attached):
 2014-02-07 06:10:14,984 - DEBUG - test_01_deploy_vm_with_implicit_planner 
 (integration.component.test_implicit_planner.TestImplicitPlanner) - Request: 
 http://207.19.99.108:8080/client/api?domainid=03ffb96f-2cfa-11e3-a4f0-f245a5b3ba0fzoneid=2010f0c3-05e5-4114-9e15-99547cd29186apiKey=fvHLVRKfsEQeejLrnRbye4XT4-j_pXMYsJxRYFxqxssppq2y4Txo1XYX2ABZ1qJD-2MNScVw24WT_QYOscA1Zgserviceofferingid=73e37a59-9b9d-429a-8d8f-26acf7a3bea8displayname=testserversignature=DynuaFeu1NgyE9wB9KhK9Uaq1eo%3Dtemplateid=dd84c28a-0526-4e04-8cd2-319b40e05e21response=jsonaccount=test-TestImplicitPlanner-URIY0Acommand=deployVirtualMachinehypervisor=XenServer
  Response: { deployvirtualmachineresponse : 
 {id:d7bbe188-ff92-411d-aa76-05baf78d0500,jobid:7226acb8-47b1-4f4a-9f7e-e91440de82a5}
  }
 2014-02-07 06:10:14,985 - DEBUG - test_01_deploy_vm_with_implicit_planner 
 (integration.component.test_implicit_planner.TestImplicitPlanner) - sending 
 GET request: queryAsyncJobResult {'jobid': 
 u'7226acb8-47b1-4f4a-9f7e-e91440de82a5'}
 2014-02-07 06:10:14,985 - DEBUG - test_01_deploy_vm_with_implicit_planner 
 (integration.component.test_implicit_planner.TestImplicitPlanner) - Computed 
 Signature by Marvin: a5n+8ad8pnEBmrzzZp1ocLXN+/Y=
 2014-02-07 06:10:15,452 - DEBUG - test_01_deploy_vm_with_implicit_planner 
 (integration.component.test_implicit_planner.TestImplicitPlanner) - Request: 
 http://207.19.99.108:8080/client/api?signature=a5n%2B8ad8pnEBmrzzZp1ocLXN%2B%2FY%3DapiKey=fvHLVRKfsEQeejLrnRbye4XT4-j_pXMYsJxRYFxqxssppq2y4Txo1XYX2ABZ1qJD-2MNScVw24WT_QYOscA1Zgcommand=queryAsyncJobResultresponse=jsonjobid=7226acb8-47b1-4f4a-9f7e-e91440de82a5
  Response: { queryasyncjobresultresponse : 
 {accountid:1baaca47-2cfa-11e3-a4f0-f245a5b3ba0f,userid:1bab389c-2cfa-11e3-a4f0-f245a5b3ba0f,cmd:org.apache.cloudstack.api.command.user.vm.DeployVMCmd,jobstatus:0,jobprocstatus:0,jobresultcode:0,jobinstancetype:VirtualMachine,jobinstanceid:d7bbe188-ff92-411d-aa76-05baf78d0500,created:2014-02-06T19:39:34-0500,jobid:7226acb8-47b1-4f4a-9f7e-e91440de82a5}
  }
 2014-02-07 06:10:20,463 - DEBUG - test_01_deploy_vm_with_implicit_planner 
 (integration.component.test_implicit_planner.TestImplicitPlanner) - job: 
 7226acb8-47b1-4f4a-9f7e-e91440de82a5 still processing,will timeout in 3600s
 .
 .
 .
 .
 .
 .
 .
 2014-02-07 07:16:09,441 - DEBUG - test_01_deploy_vm_with_implicit_planner 
 (integration.component.test_implicit_planner.TestImplicitPlanner) - job: 
 7226acb8-47b1-4f4a-9f7e-e91440de82a5 still processing,will timeout in 10s
 2014-02-07 07:16:09,442 - DEBUG - test_01_deploy_vm_with_implicit_planner 
 (integration.component.test_implicit_planner.TestImplicitPlanner) - sending 
 GET request: queryAsyncJobResult {'jobid': 
 u'7226acb8-47b1-4f4a-9f7e-e91440de82a5'}
 2014-02-07 07:16:09,442 - DEBUG - test_01_deploy_vm_with_implicit_planner 
 (integration.component.test_implicit_planner.TestImplicitPlanner) - Computed 
 Signature by Marvin: a5n+8ad8pnEBmrzzZp1ocLXN+/Y=
 2014-02-07 07:16:09,935 - DEBUG - test_01_deploy_vm_with_implicit_planner 
 (integration.component.test_implicit_planner.TestImplicitPlanner) - Request: 
 http://207.19.99.108:8080/client/api?signature=a5n%2B8ad8pnEBmrzzZp1ocLXN%2B%2FY%3DapiKey=fvHLVRKfsEQeejLrnRbye4XT4-j_pXMYsJxRYFxqxssppq2y4Txo1XYX2ABZ1qJD-2MNScVw24WT_QYOscA1Zgcommand=queryAsyncJobResultresponse=jsonjobid=7226acb8-47b1-4f4a-9f7e-e91440de82a5
  Response: { queryasyncjobresultresponse :

[jira] [Created] (CLOUDSTACK-6118) [Automation] : test_haproxy.py fails with error as cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext : u'Command failed due

Dhananjay D Pathak created CLOUDSTACK-6118:
--

 Summary: [Automation] : test_haproxy.py fails with error as 
cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode : 
530, errortext : u'Command failed due to Internal Server Error'}
 Key: CLOUDSTACK-6118
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6118
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: marvin
Affects Versions: 4.2.0
 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server 
release 6.4 (Santiago) 

Reporter: Dhananjay D Pathak


Marvin Test test_haproxy.py fails with Error as described bellow (log files are 
attached):


2014-02-06 22:53:40,775 - DEBUG - test_04_delete_lb_rule 
(integration.component.test_haproxy.TestHAProxyStickyness) - Computed Signature 
by Marvin: f+H3cgxSThUSgJjAhPXEA9LEdmo=
2014-02-06 22:53:42,712 - DEBUG - test_04_delete_lb_rule 
(integration.component.test_haproxy.TestHAProxyStickyness) - Request: 
http://207.19.99.108:8080/client/api?signature=f%2BH3cgxSThUSgJjAhPXEA9LEdmo%3DapiKey=fvHLVRKfsEQeejLrnRbye4XT4-j_pXMYsJxRYFxqxssppq2y4Txo1XYX2ABZ1qJD-2MNScVw24WT_QYOscA1Zgcommand=deleteLoadBalancerRuleid=9bd0142a-665b-41ca-982e-9f899a2e2805response=json
 Response: { deleteloadbalancerruleresponse : 
{jobid:e4e4b39f-f32a-4a00-8d4d-9cbbe87e9f51} }
2014-02-06 22:53:42,717 - DEBUG - test_04_delete_lb_rule 
(integration.component.test_haproxy.TestHAProxyStickyness) - sending GET 
request: queryAsyncJobResult {'jobid': u'e4e4b39f-f32a-4a00-8d4d-9cbbe87e9f51'}
2014-02-06 22:53:42,720 - DEBUG - test_04_delete_lb_rule 
(integration.component.test_haproxy.TestHAProxyStickyness) - Computed Signature 
by Marvin: TvwJ8gqOg8Euk0zKHMF6pveBjBc=
2014-02-06 22:53:44,587 - DEBUG - test_04_delete_lb_rule 
(integration.component.test_haproxy.TestHAProxyStickyness) - Request: 
http://207.19.99.108:8080/client/api?signature=TvwJ8gqOg8Euk0zKHMF6pveBjBc%3DapiKey=fvHLVRKfsEQeejLrnRbye4XT4-j_pXMYsJxRYFxqxssppq2y4Txo1XYX2ABZ1qJD-2MNScVw24WT_QYOscA1Zgcommand=queryAsyncJobResultresponse=jsonjobid=e4e4b39f-f32a-4a00-8d4d-9cbbe87e9f51
 Response: { queryasyncjobresultresponse : 
{accountid:1baaca47-2cfa-11e3-a4f0-f245a5b3ba0f,userid:1bab389c-2cfa-11e3-a4f0-f245a5b3ba0f,cmd:org.apache.cloudstack.api.command.user.loadbalancer.DeleteLoadBalancerRuleCmd,jobstatus:2,jobprocstatus:0,jobresultcode:530,jobresulttype:object,jobresult:{errorcode:530,errortext:Command
 failed due to Internal Server 
Error},created:2014-02-06T12:23:01-0500,jobid:e4e4b39f-f32a-4a00-8d4d-9cbbe87e9f51}
 }
2014-02-06 22:53:44,596 - CRITICAL - test_04_delete_lb_rule 
(integration.component.test_haproxy.TestHAProxyStickyness) - EXCEPTION: 
test_04_delete_lb_rule: Traceback (most recent call last):
  File /usr/local/lib/python2.7/unittest/case.py, line 327, in run
testMethod()
  File /DataDisk/temp/cloudstack/test/integration/component/test_haproxy.py, 
line 557, in test_04_delete_lb_rule
lb_rule.delete(self.apiclient)
  File /usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, 
line 1665, in delete
apiclient.deleteLoadBalancerRule(cmd)
  File 
/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
 line 973, in deleteLoadBalancerRule
response = self.connection.marvinRequest(command, response_type=response, 
method=method)
  File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, 
line 280, in marvinRequest
response = self.poll(asyncJobId, response_type)
  File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, 
line 86, in poll
asyncquery, asyncResonse.jobresult)
cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode : 
530, errortext : u'Command failed due to Internal Server Error'}

2014-02-06 22:53:44,602 - DEBUG - test_04_delete_lb_rule 
(integration.component.test_haproxy.TestHAProxyStickyness) - sending GET 
request: deleteAccount {'id': u'd1380571-2370-4596-9ee1-5a1fd652bab3'}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-6118) [Automation] : test_haproxy.py fails with error as cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext : u'Command failed due


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dhananjay D Pathak updated CLOUDSTACK-6118:
---

Attachment: runinfo.txt
results.txt
failed_plus_exceptions.txt

Log files for execution of test_haproxy.py are attached.


 [Automation] : test_haproxy.py fails with error as cloudstackAPIException: 
 Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext : 
 u'Command failed due to Internal Server Error'}
 

 Key: CLOUDSTACK-6118
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6118
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: marvin
Affects Versions: 4.2.0
 Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server 
 release 6.4 (Santiago) 
Reporter: Dhananjay D Pathak
 Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt


 Marvin Test test_haproxy.py fails with Error as described bellow (log files 
 are attached):
 2014-02-06 22:53:40,775 - DEBUG - test_04_delete_lb_rule 
 (integration.component.test_haproxy.TestHAProxyStickyness) - Computed 
 Signature by Marvin: f+H3cgxSThUSgJjAhPXEA9LEdmo=
 2014-02-06 22:53:42,712 - DEBUG - test_04_delete_lb_rule 
 (integration.component.test_haproxy.TestHAProxyStickyness) - Request: 
 http://207.19.99.108:8080/client/api?signature=f%2BH3cgxSThUSgJjAhPXEA9LEdmo%3DapiKey=fvHLVRKfsEQeejLrnRbye4XT4-j_pXMYsJxRYFxqxssppq2y4Txo1XYX2ABZ1qJD-2MNScVw24WT_QYOscA1Zgcommand=deleteLoadBalancerRuleid=9bd0142a-665b-41ca-982e-9f899a2e2805response=json
  Response: { deleteloadbalancerruleresponse : 
 {jobid:e4e4b39f-f32a-4a00-8d4d-9cbbe87e9f51} }
 2014-02-06 22:53:42,717 - DEBUG - test_04_delete_lb_rule 
 (integration.component.test_haproxy.TestHAProxyStickyness) - sending GET 
 request: queryAsyncJobResult {'jobid': 
 u'e4e4b39f-f32a-4a00-8d4d-9cbbe87e9f51'}
 2014-02-06 22:53:42,720 - DEBUG - test_04_delete_lb_rule 
 (integration.component.test_haproxy.TestHAProxyStickyness) - Computed 
 Signature by Marvin: TvwJ8gqOg8Euk0zKHMF6pveBjBc=
 2014-02-06 22:53:44,587 - DEBUG - test_04_delete_lb_rule 
 (integration.component.test_haproxy.TestHAProxyStickyness) - Request: 
 http://207.19.99.108:8080/client/api?signature=TvwJ8gqOg8Euk0zKHMF6pveBjBc%3DapiKey=fvHLVRKfsEQeejLrnRbye4XT4-j_pXMYsJxRYFxqxssppq2y4Txo1XYX2ABZ1qJD-2MNScVw24WT_QYOscA1Zgcommand=queryAsyncJobResultresponse=jsonjobid=e4e4b39f-f32a-4a00-8d4d-9cbbe87e9f51
  Response: { queryasyncjobresultresponse : 
 {accountid:1baaca47-2cfa-11e3-a4f0-f245a5b3ba0f,userid:1bab389c-2cfa-11e3-a4f0-f245a5b3ba0f,cmd:org.apache.cloudstack.api.command.user.loadbalancer.DeleteLoadBalancerRuleCmd,jobstatus:2,jobprocstatus:0,jobresultcode:530,jobresulttype:object,jobresult:{errorcode:530,errortext:Command
  failed due to Internal Server 
 Error},created:2014-02-06T12:23:01-0500,jobid:e4e4b39f-f32a-4a00-8d4d-9cbbe87e9f51}
  }
 2014-02-06 22:53:44,596 - CRITICAL - test_04_delete_lb_rule 
 (integration.component.test_haproxy.TestHAProxyStickyness) - EXCEPTION: 
 test_04_delete_lb_rule: Traceback (most recent call last):
   File /usr/local/lib/python2.7/unittest/case.py, line 327, in run
 testMethod()
   File 
 /DataDisk/temp/cloudstack/test/integration/component/test_haproxy.py, line 
 557, in test_04_delete_lb_rule
 lb_rule.delete(self.apiclient)
   File 
 /usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, line 
 1665, in delete
 apiclient.deleteLoadBalancerRule(cmd)
   File 
 /usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
  line 973, in deleteLoadBalancerRule
 response = self.connection.marvinRequest(command, response_type=response, 
 method=method)
   File 
 /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 
 280, in marvinRequest
 response = self.poll(asyncJobId, response_type)
   File 
 /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 
 86, in poll
 asyncquery, asyncResonse.jobresult)
 cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode : 
 530, errortext : u'Command failed due to Internal Server Error'}
 2014-02-06 22:53:44,602 - DEBUG - test_04_delete_lb_rule 
 (integration.component.test_haproxy.TestHAProxyStickyness) - sending GET 
 request: deleteAccount {'id': u'd1380571-2370-4596-9ee1-5a1fd652bab3'}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (CLOUDSTACK-6069) can't create privatgateway with vlan in a mixed network env

2014-02-14 Thread Daan Hoogland (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daan Hoogland resolved CLOUDSTACK-6069.
---

Resolution: Not A Problem
  Assignee: Daan Hoogland

The old testcase is actually faulty as it catches an exception and silently 
fails. The user should have been notified of the failure. Thought the 530 
server error is quite a crude way to do so, the present behavior is actually an 
improvement.

 can't create privatgateway with vlan in a mixed network env
 ---

 Key: CLOUDSTACK-6069
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6069
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller, Xen
Affects Versions: 4.3.0
 Environment: 1 zone, 1 pod, 1 cluster, 2 hosts (xen 6.0.2)
 2 physnets
 - physnet 1 vlan based (Public, Guest(tagged vlan-based), Management, 
 Storage)
 - physnet 2 nicira based (Guest (tagged nicira-based))
Reporter: Daan Hoogland
Assignee: Daan Hoogland

 creating a private gateway on a vpc with a vlan fails.
 I get a 530 server error using marvin to create the net. in 4.2.1 this didn't 
 happen
 4.2.1 code (succeeding):
 2014-02-10 15:43:45,621 DEBUG [xen.resource.CitrixResourceBase]
 (DirectAgent-4:null) Creating VLAN 322 on host 10.200.23.41 on device
 tunnel0
 4.3.0 code (failing)
 2014-02-10 17:33:51,083 DEBUG [c.c.h.x.r.CitrixResourceBase]
 (DirectAgent-4:ctx-6d5f0cd4) Creating VLAN 322 on host 10.200.23.42 on
 device tunnel0



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5967) Virtual router in OVS network fails to start with error from XenServer: VM_REQUIRES_NETWORK

2014-02-14 Thread Murali Reddy (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901615#comment-13901615
 ] 

Murali Reddy commented on CLOUDSTACK-5967:
--



Thanks for testing and finding the issue. I am pretty sure this scenario
never worked. Fix is simple, but not sure we can get this into 4.3, given
its not regression. Will get this in if there is a new RC.





 Virtual router in OVS network fails to start with error from XenServer: 
 VM_REQUIRES_NETWORK
 ---

 Key: CLOUDSTACK-5967
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5967
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.3.0
 Environment: CloudStack 4.3 with XenServer 6.2
 GRE tunnel based advanced network 
Reporter: Paul Angus
Assignee: Murali Reddy
Priority: Blocker
 Fix For: 4.3.0


 Virtual Router start fails with error VM_REQUIRES_NETWORK when using GRE 
 tunnel encapsulation.
 Tunnel is created on XenServer (OVSTunnel194)
 virtual router appears briefly then dissappears and insufficient capacity 
 error is returned by cloudstack
 2014-01-28 16:17:09,829 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (Job-Executor-12:ctx-3a256248 ctx-58300764) Creating  monitoring services on 
 VM[DomainRouter|r-12-VM] start...
 2014-01-28 16:17:09,842 DEBUG [c.c.a.t.Request] (Job-Executor-12:ctx-3a256248 
 ctx-58300764) Seq 2-232063002: Sending  { Cmd , MgmtId: 345049362040, via: 
 2(localhost.localdomain), Ver: v1, Flags: 100011, 
 [{com.cloud.agent.api.StartCommand:{vm:{id:12,name:r-12-VM,bootloader:PyGrub,type:DomainRouter,cpus:1,minSpeed:125,maxSpeed:500,minRam:134217728,maxRam:134217728,arch:x86_64,os:Debian
  GNU/Linux 7(32-bit),bootArgs: template=domP name=r-12-VM 
 eth2ip=192.168.1.53 eth2mask=255.255.255.0 gateway=192.168.1.254 
 eth0ip=10.1.1.1 eth0mask=255.255.255.0 domain=cs2cloud.internal 
 dhcprange=10.1.1.1 eth1ip=169.254.0.255 eth1mask=255.255.0.0 type=router 
 disable_rp_filter=true

[jira] [Created] (CLOUDSTACK-6119) CentOS 5.3(64-bit) no GUI (XenServer) Template is being downloaded and then deleted

2014-02-14 Thread Geoff Higgibottom (JIRA)

Geoff Higgibottom created CLOUDSTACK-6119:
-

 Summary: CentOS 5.3(64-bit) no GUI (XenServer) Template is being 
downloaded and then deleted
 Key: CLOUDSTACK-6119
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6119
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Install and Setup, Template
Affects Versions: 4.3.0
 Environment: CS 4.3.0 running on CentOS 6.5, XenServer 6.2
Reporter: Geoff Higgibottom
Priority: Minor


When deploying a new zone using 4.3.0 the SSVM downloads the default XenServer 
Template 'CentOS 5.6(64-bit) no GUI (XenServer)'

I noticed whilst monitoring Secondary Storage and the CPU usage of the SSVM 
that it is also downloading the old 'CentOS 5.3(64-bit) no GUI (XenServer)' as 
well.

If left alone, this template will fully download into .../template/tmpl/1/2/ on 
Secondary Storage but then once downloaded it will get deleted.

If however during the download the 'state' in the DB table 'vm_templates' is 
changed to 'Active' the template appears in the UI and is usable (just to prove 
it is actually downloaded etc).

This is an old retired example template which has been superseded by the newer 
5.6 version so downloading then deleting it is a waste of resource, especially 
on small test builds etc.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6120) Order of templates and ISOs not honored by UI or API

Jessica Wang created CLOUDSTACK-6120:


 Summary: Order of templates and ISOs not honored by UI or API
 Key: CLOUDSTACK-6120
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6120
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang


there is a problem with the order of UpdateTemplate/ISO API calls in case of 
multiple zones.
 If a template is registered on multiple zones while listing we show multiple 
entries of that template (one entry for each zone), but the UUID of the 
template is same. 

Say from UI listtemplates looks like this,

T2 - Zone1 (UUID = )
 T2 - Zone2 (UUID = )
 T3 - Zone1 (UUID = )
 T3 - Zone2 (UUID = )
 T1 - Zone1 (UUID = )
 T1 - Zone2 (UUID = )

If I pull T1 - Zone1 to first position

From UI updatetemplate APIs are called in this order.

UpdateTemplate API T1 - Zone1 with sort_key 6 and UUID = 
 UpdateTemplate API T2 - Zone1 with sort_key 5 and UUID = 
 UpdateTemplate API T2 - Zone2 with sort_key 4 and UUID = 
 UpdateTemplate API T3 - Zone1 with sort_key 3 and UUID = 
 UpdateTemplate API T3 - Zone2 with sort_key 2 and UUID = 
 UpdateTemplate API T1 - Zone2 with sort_key 1 and UUID = 

Even If I pull T1 to first position the last updateTemplate API call on T1 is 
with sort_key 1. So it will stay at last position again.

So from UI if we call updateTemplate/ISO only one time (starting from top) by 
maintaining a HaspMap of UUIDs it may solve the problem.
 Update API looks like this

UpdateTemplate API T1 - Zone1 with sort_key 6
 UpdateTemplate API T2 - Zone1 with sort_key 5
 UpdateTemplate API T3 - Zone1 with sort_key 3




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-6120) Order of templates and ISOs not honored by UI or API

2014-02-14 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901922#comment-13901922
 ] 

Jessica Wang commented on CLOUDSTACK-6120:
--

http://bugs-ccp.citrix.com/browse/CS-18605

 Order of templates and ISOs not honored by UI or API
 

 Key: CLOUDSTACK-6120
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6120
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang

 there is a problem with the order of UpdateTemplate/ISO API calls in case of 
 multiple zones.
  If a template is registered on multiple zones while listing we show multiple 
 entries of that template (one entry for each zone), but the UUID of the 
 template is same. 
 Say from UI listtemplates looks like this,
 T2 - Zone1 (UUID = )
  T2 - Zone2 (UUID = )
  T3 - Zone1 (UUID = )
  T3 - Zone2 (UUID = )
  T1 - Zone1 (UUID = )
  T1 - Zone2 (UUID = )
 If I pull T1 - Zone1 to first position
 From UI updatetemplate APIs are called in this order.
 UpdateTemplate API T1 - Zone1 with sort_key 6 and UUID = 
  UpdateTemplate API T2 - Zone1 with sort_key 5 and UUID = 
  UpdateTemplate API T2 - Zone2 with sort_key 4 and UUID = 
  UpdateTemplate API T3 - Zone1 with sort_key 3 and UUID = 
  UpdateTemplate API T3 - Zone2 with sort_key 2 and UUID = 
  UpdateTemplate API T1 - Zone2 with sort_key 1 and UUID = 
 Even If I pull T1 to first position the last updateTemplate API call on T1 is 
 with sort_key 1. So it will stay at last position again.
 So from UI if we call updateTemplate/ISO only one time (starting from top) by 
 maintaining a HaspMap of UUIDs it may solve the problem.
  Update API looks like this
 UpdateTemplate API T1 - Zone1 with sort_key 6
  UpdateTemplate API T2 - Zone1 with sort_key 5
  UpdateTemplate API T3 - Zone1 with sort_key 3



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-6120) Order of templates and ISOs not honored by UI or API


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901928#comment-13901928
 ] 

ASF subversion and git services commented on CLOUDSTACK-6120:
-

Commit e1e16a2301a75c6746bdb69774a6d9fb996455ca in cloudstack's branch 
refs/heads/master from [~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e1e16a2 ]

CLOUDSTACK-6120: UI  listView widget  sorting order  fire only one sorting 
API call(updateXXXsortKey=nid=UUID) for items who have the same UUID.
e.g. An Template/ISO of multiple zones have the same UUID.


 Order of templates and ISOs not honored by UI or API
 

 Key: CLOUDSTACK-6120
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6120
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang

 there is a problem with the order of UpdateTemplate/ISO API calls in case of 
 multiple zones.
  If a template is registered on multiple zones while listing we show multiple 
 entries of that template (one entry for each zone), but the UUID of the 
 template is same. 
 Say from UI listtemplates looks like this,
 T2 - Zone1 (UUID = )
  T2 - Zone2 (UUID = )
  T3 - Zone1 (UUID = )
  T3 - Zone2 (UUID = )
  T1 - Zone1 (UUID = )
  T1 - Zone2 (UUID = )
 If I pull T1 - Zone1 to first position
 From UI updatetemplate APIs are called in this order.
 UpdateTemplate API T1 - Zone1 with sort_key 6 and UUID = 
  UpdateTemplate API T2 - Zone1 with sort_key 5 and UUID = 
  UpdateTemplate API T2 - Zone2 with sort_key 4 and UUID = 
  UpdateTemplate API T3 - Zone1 with sort_key 3 and UUID = 
  UpdateTemplate API T3 - Zone2 with sort_key 2 and UUID = 
  UpdateTemplate API T1 - Zone2 with sort_key 1 and UUID = 
 Even If I pull T1 to first position the last updateTemplate API call on T1 is 
 with sort_key 1. So it will stay at last position again.
 So from UI if we call updateTemplate/ISO only one time (starting from top) by 
 maintaining a HaspMap of UUIDs it may solve the problem.
  Update API looks like this
 UpdateTemplate API T1 - Zone1 with sort_key 6
  UpdateTemplate API T2 - Zone1 with sort_key 5
  UpdateTemplate API T3 - Zone1 with sort_key 3



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Closed] (CLOUDSTACK-6120) Order of templates and ISOs not honored by UI or API


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jessica Wang closed CLOUDSTACK-6120.



 Order of templates and ISOs not honored by UI or API
 

 Key: CLOUDSTACK-6120
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6120
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang

 there is a problem with the order of UpdateTemplate/ISO API calls in case of 
 multiple zones.
  If a template is registered on multiple zones while listing we show multiple 
 entries of that template (one entry for each zone), but the UUID of the 
 template is same. 
 Say from UI listtemplates looks like this,
 T2 - Zone1 (UUID = )
  T2 - Zone2 (UUID = )
  T3 - Zone1 (UUID = )
  T3 - Zone2 (UUID = )
  T1 - Zone1 (UUID = )
  T1 - Zone2 (UUID = )
 If I pull T1 - Zone1 to first position
 From UI updatetemplate APIs are called in this order.
 UpdateTemplate API T1 - Zone1 with sort_key 6 and UUID = 
  UpdateTemplate API T2 - Zone1 with sort_key 5 and UUID = 
  UpdateTemplate API T2 - Zone2 with sort_key 4 and UUID = 
  UpdateTemplate API T3 - Zone1 with sort_key 3 and UUID = 
  UpdateTemplate API T3 - Zone2 with sort_key 2 and UUID = 
  UpdateTemplate API T1 - Zone2 with sort_key 1 and UUID = 
 Even If I pull T1 to first position the last updateTemplate API call on T1 is 
 with sort_key 1. So it will stay at last position again.
 So from UI if we call updateTemplate/ISO only one time (starting from top) by 
 maintaining a HaspMap of UUIDs it may solve the problem.
  Update API looks like this
 UpdateTemplate API T1 - Zone1 with sort_key 6
  UpdateTemplate API T2 - Zone1 with sort_key 5
  UpdateTemplate API T3 - Zone1 with sort_key 3



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (CLOUDSTACK-6120) Order of templates and ISOs not honored by UI or API


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jessica Wang resolved CLOUDSTACK-6120.
--

Resolution: Fixed

 Order of templates and ISOs not honored by UI or API
 

 Key: CLOUDSTACK-6120
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6120
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang

 there is a problem with the order of UpdateTemplate/ISO API calls in case of 
 multiple zones.
  If a template is registered on multiple zones while listing we show multiple 
 entries of that template (one entry for each zone), but the UUID of the 
 template is same. 
 Say from UI listtemplates looks like this,
 T2 - Zone1 (UUID = )
  T2 - Zone2 (UUID = )
  T3 - Zone1 (UUID = )
  T3 - Zone2 (UUID = )
  T1 - Zone1 (UUID = )
  T1 - Zone2 (UUID = )
 If I pull T1 - Zone1 to first position
 From UI updatetemplate APIs are called in this order.
 UpdateTemplate API T1 - Zone1 with sort_key 6 and UUID = 
  UpdateTemplate API T2 - Zone1 with sort_key 5 and UUID = 
  UpdateTemplate API T2 - Zone2 with sort_key 4 and UUID = 
  UpdateTemplate API T3 - Zone1 with sort_key 3 and UUID = 
  UpdateTemplate API T3 - Zone2 with sort_key 2 and UUID = 
  UpdateTemplate API T1 - Zone2 with sort_key 1 and UUID = 
 Even If I pull T1 to first position the last updateTemplate API call on T1 is 
 with sort_key 1. So it will stay at last position again.
 So from UI if we call updateTemplate/ISO only one time (starting from top) by 
 maintaining a HaspMap of UUIDs it may solve the problem.
  Update API looks like this
 UpdateTemplate API T1 - Zone1 with sort_key 6
  UpdateTemplate API T2 - Zone1 with sort_key 5
  UpdateTemplate API T3 - Zone1 with sort_key 3



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5907) KVM/CLVM volumes are shown as Ovm hypervisor


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901957#comment-13901957
 ] 

Nux commented on CLOUDSTACK-5907:
-

not able to reproduce with latest 4.3 RC, closing

 KVM/CLVM volumes are shown as Ovm hypervisor
 

 Key: CLOUDSTACK-5907
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5907
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, KVM, Oracle VM (OVM), Storage Controller, UI
Affects Versions: 4.2.1, 4.3.0
 Environment: KVM, CLVM
Reporter: Nux
  Labels: clvm, kvm, ovm, storage

 It looks like ACS is showing KVM volumes on CLVM primary storage as being for 
 Oracle hypervisor.
 http://i.imgur.com/E4InCV2.png
 The API shows the same so it's not a UI glitch.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Closed] (CLOUDSTACK-5907) KVM/CLVM volumes are shown as Ovm hypervisor


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nux closed CLOUDSTACK-5907.
---

Resolution: Fixed

 KVM/CLVM volumes are shown as Ovm hypervisor
 

 Key: CLOUDSTACK-5907
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5907
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, KVM, Oracle VM (OVM), Storage Controller, UI
Affects Versions: 4.2.1, 4.3.0
 Environment: KVM, CLVM
Reporter: Nux
  Labels: clvm, kvm, ovm, storage

 It looks like ACS is showing KVM volumes on CLVM primary storage as being for 
 Oracle hypervisor.
 http://i.imgur.com/E4InCV2.png
 The API shows the same so it's not a UI glitch.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5524) [UI]root disk size field should be removed from the add instance wizard since this feature is not implemented


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901964#comment-13901964
 ] 

Nux commented on CLOUDSTACK-5524:
-

this has been fixed in latest 4.3 RC

 [UI]root disk size field should be removed from the add instance wizard 
 since this feature is not implemented
 ---

 Key: CLOUDSTACK-5524
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5524
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.3.0
Reporter: prashant kumar mishra
Assignee: Alex Hitchins
Priority: Minor
 Fix For: 4.3.0

 Attachments: screenshot-1.jpg


 please check screenshot



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6121) Putting primary storage in maintenance mode does not shut down the VMs

Nux created CLOUDSTACK-6121:
---

 Summary: Putting primary storage in maintenance mode does not shut 
down the VMs
 Key: CLOUDSTACK-6121
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6121
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: KVM, Storage Controller, SystemVM
Affects Versions: 4.3.0
 Environment: CentOS 6.5, KVM, NFS
Reporter: Nux


According to the docs, when putting the primary storage in maintenance mode all 
the VMs hosted on it shut be shutdown.

This does not happen in reality, the console proxy VM seems to be the only one 
that gets shut down but then it triggers a series of errors like:

2014-02-14 21:32:29,269 WARN  [c.c.c.ConsoleProxyManagerImpl] 
(consoleproxy-1:ctx-5bc8688f) Exception while trying to start console proxy
com.cloud.exception.InsufficientServerCapacityException: Unable to create a 
deployment for VM[ConsoleProxy|v-1-VM]Scope=interface com.cloud.dc.DataCenter; 
id=1
 (more here http://fpaste.org/77417/41354413/ )

It all gets stuck because of the system vm. `virsh list` is showing the other 
VMs running just fine.




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5863) Restore volume snapshot