[jira] [Closed] (CLOUDSTACK-7053) [Automation] Tasks for writing automated test cases for few product bugs

2014-09-04 Thread Srikanteswararao Talluri (JIRA) 

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

Srikanteswararao Talluri closed CLOUDSTACK-7053.


 [Automation] Tasks for writing automated test cases for few product bugs
 

 Key: CLOUDSTACK-7053
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7053
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Test
Affects Versions: 4.5.0
Reporter: Srikanteswararao Talluri
Assignee: Srikanteswararao Talluri
 Fix For: 4.5.0






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

[jira] [Resolved] (CLOUDSTACK-7053) [Automation] Tasks for writing automated test cases for few product bugs

2014-09-04 Thread Srikanteswararao Talluri (JIRA) 

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

Srikanteswararao Talluri resolved CLOUDSTACK-7053.
--
Resolution: Fixed

 [Automation] Tasks for writing automated test cases for few product bugs
 

 Key: CLOUDSTACK-7053
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7053
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Test
Affects Versions: 4.5.0
Reporter: Srikanteswararao Talluri
Assignee: Srikanteswararao Talluri
 Fix For: 4.5.0






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

[jira] [Resolved] (CLOUDSTACK-5887) [Automation] test_04_reoccuring_snapshot_rules test cases failing with error Exception not raised

2014-09-04 Thread Gaurav Aradhye (JIRA) 

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

Gaurav Aradhye resolved CLOUDSTACK-5887.

Resolution: Fixed

 [Automation] test_04_reoccuring_snapshot_rules test cases failing with error 
 Exception not raised
 ---

 Key: CLOUDSTACK-5887
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5887
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.3.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
 Fix For: 4.3.0


 Run Regression_Advanced_KVM_60_Multi 250 
 Test case 
 integration.component.test_base_image_updation.TestBaseImageUpdate.test_04_reoccuring_snapshot_rules
  failed with below exception 
 test_04_reoccuring_snapshot_rules 
 (integration.component.test_base_image_updation.TestBaseImageUpdate): DEBUG: 
 sending GET request: listSnapshotPolicies {'volumeid': 
 u'25137726-bf49-4cf1-ba70-bec5f5a3c797'}
 test_04_reoccuring_snapshot_rules 
 (integration.component.test_base_image_updation.TestBaseImageUpdate): DEBUG: 
 Computed Signature by Marvin: iBlsyp5r6eX3vafeA87SjLnpjcQ=
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.49.195
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?apiKey=1JEaK3o398-0hKchIDyIGIeLr8P7vP5lrFeBEvWlpjEryj7MmTKekzWdsqyMvRhaxFTaDAO3pcbmTSMbtokUnQvolumeid=25137726-bf49-4cf1-ba70-bec5f5a3c797command=listSnapshotPoliciessignature=iBlsyp5r6eX3vafeA87SjLnpjcQ%3Dresponse=json
  HTTP/1.1 200 40
 test_04_reoccuring_snapshot_rules 
 (integration.component.test_base_image_updation.TestBaseImageUpdate): DEBUG: 
 Request: 
 http://10.223.49.195:8080/client/api?apiKey=1JEaK3o398-0hKchIDyIGIeLr8P7vP5lrFeBEvWlpjEryj7MmTKekzWdsqyMvRhaxFTaDAO3pcbmTSMbtokUnQvolumeid=25137726-bf49-4cf1-ba70-bec5f5a3c797command=listSnapshotPoliciessignature=iBlsyp5r6eX3vafeA87SjLnpjcQ%3Dresponse=json
  Response: { listsnapshotpoliciesresponse : { } }
 test_04_reoccuring_snapshot_rules 
 (integration.component.test_base_image_updation.TestBaseImageUpdate): 
 CRITICAL: FAILED: test_04_reoccuring_snapshot_rules: Traceback (most recent 
 call last):
   File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
 testMethod()
   File 
 /Repo_30X/ipcl/cloudstack/test/integration/component/test_base_image_updation.py,
  line 644, in test_04_reoccuring_snapshot_rules
 volumeid=vm_with_reset_root_disk_id
   File /usr/local/lib/python2.7/unittest/case.py, line 112, in __exit__
 {0} not raised.format(exc_name))
 AssertionError: Exception not raised
 -  end captured logging  -
 Stacktrace
   File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
 testMethod()
   File 
 /Repo_30X/ipcl/cloudstack/test/integration/component/test_base_image_updation.py,
  line 644, in test_04_reoccuring_snapshot_rules
 volumeid=vm_with_reset_root_disk_id
   File /usr/local/lib/python2.7/unittest/case.py, line 112, in __exit__
 {0} not raised.format(exc_name))
 Exception not raised
   begin captured logging  
 It will be great if we can add some more meaning full messages



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

[jira] [Closed] (CLOUDSTACK-5887) [Automation] test_04_reoccuring_snapshot_rules test cases failing with error Exception not raised

2014-09-04 Thread Gaurav Aradhye (JIRA) 

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

Gaurav Aradhye closed CLOUDSTACK-5887.
--

The issue is fixed as seen in KVM build #452.
It has failed in later run due to reboot issue which is different from this 
one. Hence closing this issue.

The reboot issue needs to be investigated separately and fresh test/product bug 
should be logged.

 [Automation] test_04_reoccuring_snapshot_rules test cases failing with error 
 Exception not raised
 ---

 Key: CLOUDSTACK-5887
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5887
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.3.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
 Fix For: 4.3.0


 Run Regression_Advanced_KVM_60_Multi 250 
 Test case 
 integration.component.test_base_image_updation.TestBaseImageUpdate.test_04_reoccuring_snapshot_rules
  failed with below exception 
 test_04_reoccuring_snapshot_rules 
 (integration.component.test_base_image_updation.TestBaseImageUpdate): DEBUG: 
 sending GET request: listSnapshotPolicies {'volumeid': 
 u'25137726-bf49-4cf1-ba70-bec5f5a3c797'}
 test_04_reoccuring_snapshot_rules 
 (integration.component.test_base_image_updation.TestBaseImageUpdate): DEBUG: 
 Computed Signature by Marvin: iBlsyp5r6eX3vafeA87SjLnpjcQ=
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.49.195
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?apiKey=1JEaK3o398-0hKchIDyIGIeLr8P7vP5lrFeBEvWlpjEryj7MmTKekzWdsqyMvRhaxFTaDAO3pcbmTSMbtokUnQvolumeid=25137726-bf49-4cf1-ba70-bec5f5a3c797command=listSnapshotPoliciessignature=iBlsyp5r6eX3vafeA87SjLnpjcQ%3Dresponse=json
  HTTP/1.1 200 40
 test_04_reoccuring_snapshot_rules 
 (integration.component.test_base_image_updation.TestBaseImageUpdate): DEBUG: 
 Request: 
 http://10.223.49.195:8080/client/api?apiKey=1JEaK3o398-0hKchIDyIGIeLr8P7vP5lrFeBEvWlpjEryj7MmTKekzWdsqyMvRhaxFTaDAO3pcbmTSMbtokUnQvolumeid=25137726-bf49-4cf1-ba70-bec5f5a3c797command=listSnapshotPoliciessignature=iBlsyp5r6eX3vafeA87SjLnpjcQ%3Dresponse=json
  Response: { listsnapshotpoliciesresponse : { } }
 test_04_reoccuring_snapshot_rules 
 (integration.component.test_base_image_updation.TestBaseImageUpdate): 
 CRITICAL: FAILED: test_04_reoccuring_snapshot_rules: Traceback (most recent 
 call last):
   File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
 testMethod()
   File 
 /Repo_30X/ipcl/cloudstack/test/integration/component/test_base_image_updation.py,
  line 644, in test_04_reoccuring_snapshot_rules
 volumeid=vm_with_reset_root_disk_id
   File /usr/local/lib/python2.7/unittest/case.py, line 112, in __exit__
 {0} not raised.format(exc_name))
 AssertionError: Exception not raised
 -  end captured logging  -
 Stacktrace
   File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
 testMethod()
   File 
 /Repo_30X/ipcl/cloudstack/test/integration/component/test_base_image_updation.py,
  line 644, in test_04_reoccuring_snapshot_rules
 volumeid=vm_with_reset_root_disk_id
   File /usr/local/lib/python2.7/unittest/case.py, line 112, in __exit__
 {0} not raised.format(exc_name))
 Exception not raised
   begin captured logging  
 It will be great if we can add some more meaning full messages



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

[jira] [Closed] (CLOUDSTACK-6439) [Automation] Two Test Cases failed on test_disk_offerings.py - provision type is not returned by listDiskOfferings response

2014-09-04 Thread Gaurav Aradhye (JIRA) 

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

Gaurav Aradhye closed CLOUDSTACK-6439.
--
Resolution: Fixed

The test cases were removed from 4.4 branch and retained only in the master 
branch as the feature is not present in 4.4.

The test cases run successfully on master branch as seen in the latest BVT 
Advanced KVM build #551 (2nd Sept, 2014). Hence closing this bug.

 [Automation] Two Test Cases failed on test_disk_offerings.py - provision 
 type is not returned by listDiskOfferings response
 -

 Key: CLOUDSTACK-6439
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6439
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, IAM
Affects Versions: 4.4.0
 Environment: Basic Zone
 XenServer 
Reporter: Chandan Purushothama
Assignee: Chandan Purushothama
Priority: Critical
 Fix For: 4.4.0


 Two Cases failed:
 1. test_02_create_sparse_type_disk_offering
 2. test_04_create_fat_type_disk_offering
 =
 Assertion Errors:
 =
 *Assertion Error 1*
 Check provisionig type in createServiceOffering
   begin captured logging  
 test_02_create_sparse_type_disk_offering 
 (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: 
 STARTED : TC: test_02_create_sparse_type_disk_offering :::
 test_02_create_sparse_type_disk_offering 
 (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: 
 sending GET request: createDiskOffering {'name': 'Sparse Type Disk offering', 
 'disksize': 1, 'displaytext': 'Sparse Type Disk offering'}
 test_02_create_sparse_type_disk_offering 
 (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: 
 Computed Signature by Marvin: m0/TZdrSBwiGRHLEVS5pdjF/y0U=
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.240.161
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qname=Sparse+Type+Disk+offeringcommand=createDiskOfferingdisksize=1signature=m0%2FTZdrSBwiGRHLEVS5pdjF%2Fy0U%3Ddisplaytext=Sparse+Type+Disk+offeringresponse=json
  HTTP/1.1 200 297
 test_02_create_sparse_type_disk_offering 
 (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: 
 Request: 
 http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qname=Sparse+Type+Disk+offeringcommand=createDiskOfferingdisksize=1signature=m0%2FTZdrSBwiGRHLEVS5pdjF%2Fy0U%3Ddisplaytext=Sparse+Type+Disk+offeringresponse=json
  Response: { creatediskofferingresponse :  { diskoffering : 
 {id:ffece54d-6736-4d72-8426-6eeade833db8,name:Sparse Type Disk 
 offering,displaytext:Sparse Type Disk 
 offering,disksize:1,created:2014-04-16T15:52:37-0700,iscustomized:false,storagetype:shared,displayoffering:true}
  }  }
 test_02_create_sparse_type_disk_offering 
 (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: 
 Created Disk offering with ID: ffece54d-6736-4d72-8426-6eeade833db8
 test_02_create_sparse_type_disk_offering 
 (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: 
 sending GET request: listDiskOfferings {'id': 
 u'ffece54d-6736-4d72-8426-6eeade833db8'}
 test_02_create_sparse_type_disk_offering 
 (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: 
 Computed Signature by Marvin: XtzgOFFqAn/1FdLA2F+/yDvHKbQ=
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.240.161
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qid=ffece54d-6736-4d72-8426-6eeade833db8command=listDiskOfferingssignature=XtzgOFFqAn%2F1FdLA2F%2B%2FyDvHKbQ%3Dresponse=json
  HTTP/1.1 200 310
 test_02_create_sparse_type_disk_offering 
 (integration.smoke.test_disk_offerings.TestCreateDiskOffering): DEBUG: 
 Request: 
 http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qid=ffece54d-6736-4d72-8426-6eeade833db8command=listDiskOfferingssignature=XtzgOFFqAn%2F1FdLA2F%2B%2FyDvHKbQ%3Dresponse=json
  Response: { listdiskofferingsresponse : { count:1 ,diskoffering : [  
 {id:ffece54d-6736-4d72-8426-6eeade833db8,name:Sparse Type Disk 
 offering,displaytext:Sparse Type Disk 
 offering,disksize:1,created:2014-04-16T15:52:37-0700,iscustomized:false,storagetype:shared,displayoffering:true}
  ] } }

[jira] [Closed] (CLOUDSTACK-4444) Can not create Vm using Cloud stack 4.2 and Xenserver6.0

2014-09-04 Thread Gaurav Aradhye (JIRA) 

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

Gaurav Aradhye closed CLOUDSTACK-.
--
Resolution: Incomplete

From the logs it seems like the issue is in the setup capacity and not related 
to product bug. Almost an year old issue and nobody is working on it, neither 
reporter has provided has any further comments after logging it.

Closing the issue as incomplete.

 Can not create Vm using Cloud stack 4.2 and Xenserver6.0
 

 Key: CLOUDSTACK-
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, XenServer
Affects Versions: 4.2.0
 Environment: Debian and Xenserver
Reporter: vaibhav srivastava

 I get following errors while trying to create VM using default centos 
 template:
 DEBUG [agent.transport.Request] (Job-Executor-8:job-8 = [ 
 dd359f97-633c-4f2b-9457-08f4f3804f8d ]) Seq 1-1674248267: Sending  { Cmd , 
 MgmtId: 70787609328613, via: 1, Ver: v1, Flags: 100011, 
 [{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:a83903a1-22fd-4fca-b7ed-3ab7ffa4d3ec,origUrl:http://download.cloud.com/templates/4.2/systemvmtemplate-2013-06-12-master-xen.vhd.bz2,uuid:4e10319f-0af1-11e3-ab63-4061864efbe5,id:1,format:VHD,accountId:1,checksum:fb1b6e032a160d86f2c28feb5add6d83,hvm:false,displayText:SystemVM
  Template 
 (XenServer),imageDataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:eb5eebc4-4cc9-3dcb-9a25-2cefca41e934,id:1,poolType:NetworkFilesystem,host:192.168.1.2,path:/export1/primary/primary123,port:2049}},name:routing-1,hypervisorType:XenServer}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:ddf51060-6a3e-4b6f-8767-5b982d11b392,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:eb5eebc4-4cc9-3dcb-9a25-2cefca41e934,id:1,poolType:NetworkFilesystem,host:192.168.1.2,path:/export1/primary/primary123,port:2049}},name:ROOT-4,size:2101252608,volumeId:5,vmName:r-4-VM,accountId:1,format:VHD,id:5,hypervisorType:None}},executeInSequence:false,wait:0}}]
  }
 DEBUG [agent.transport.Request] (Job-Executor-8:job-8 = [ 
 dd359f97-633c-4f2b-9457-08f4f3804f8d ]) Seq 1-1674248267: Executing:  { Cmd , 
 MgmtId: 70787609328613, via: 1, Ver: v1, Flags: 100011, 
 [{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:a83903a1-22fd-4fca-b7ed-3ab7ffa4d3ec,origUrl:http://download.cloud.com/templates/4.2/systemvmtemplate-2013-06-12-master-xen.vhd.bz2,uuid:4e10319f-0af1-11e3-ab63-4061864efbe5,id:1,format:VHD,accountId:1,checksum:fb1b6e032a160d86f2c28feb5add6d83,hvm:false,displayText:SystemVM
  Template 
 (XenServer),imageDataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:eb5eebc4-4cc9-3dcb-9a25-2cefca41e934,id:1,poolType:NetworkFilesystem,host:192.168.1.2,path:/export1/primary/primary123,port:2049}},name:routing-1,hypervisorType:XenServer}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:ddf51060-6a3e-4b6f-8767-5b982d11b392,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:eb5eebc4-4cc9-3dcb-9a25-2cefca41e934,id:1,poolType:NetworkFilesystem,host:192.168.1.2,path:/export1/primary/primary123,port:2049}},name:ROOT-4,size:2101252608,volumeId:5,vmName:r-4-VM,accountId:1,format:VHD,id:5,hypervisorType:None}},executeInSequence:false,wait:0}}]
  }
 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-120:) Seq 1-1674248267: 
 Executing request
 DEBUG [xen.resource.XenServerStorageProcessor] (DirectAgent-120:) Succesfully 
 created VDI: Uuid = 03f59c06-5704-4999-a4f0-50376a4618f4
 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-120:) Seq 1-1674248267: 
 Response Received: 
 DEBUG [agent.transport.Request] (DirectAgent-120:) Seq 1-1674248267: 
 Processing:  { Ans: , MgmtId: 70787609328613, via: 1, Ver: v1, Flags: 10, 
 [{org.apache.cloudstack.storage.command.CopyCmdAnswer:{newData:{org.apache.cloudstack.storage.to.VolumeObjectTO:{name:ROOT-4,size:2097152000,path:03f59c06-5704-4999-a4f0-50376a4618f4,accountId:0,id:0}},result:true,wait:0}}]
  }
 DEBUG [agent.transport.Request] (Job-Executor-8:job-8 = [ 
 dd359f97-633c-4f2b-9457-08f4f3804f8d ]) Seq 1-1674248267: Received:  { Ans: , 
 MgmtId: 70787609328613, via: 1, Ver: v1, Flags: 10, { CopyCmdAnswer } }
 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] 
 (Job-Executor-8:job-8 = [ dd359f97-633c-4f2b-9457-08f4f3804f8d ]) Boot Args 
 for VM[DomainRouter|r-4-VM]:  template=domP name=r-4-VM eth0ip=192.168.1.44 
 eth0mask=255.255.255.0 gateway=192.168.1.1 domain=cs1cloud.internal 
 dhcprange=192.168.1.1

[jira] [Commented] (CLOUDSTACK-5851) add a nic to vm failed

2014-09-04 Thread Gaurav Aradhye (JIRA) 

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

Gaurav Aradhye commented on CLOUDSTACK-5851:


Hello [~kendazheng] , Can you please update this issue? Can this be closed?

 add a nic to vm failed
 --

 Key: CLOUDSTACK-5851
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5851
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.1.0
 Environment: cloudstack4.1.0 and xenserver6.0
Reporter: zhenglei

 1. Create a vm successfully in an advanced zone.
 2. Create a network with the default networkoffering successfully. There is 
 no vm in the network now, and also the vrouter is not started.
 3. Add the network to the vm by calling the restful api successfully.
 4. But when I login the cloudstack ui,  I find the new network vrouter is not 
 started and its status is ”starting“. so add nic operation is failed.
 5. I want to check the vrouter by xencenter, but there is no this vrouter.
 6. At last, i check the management server log files, There is no any ERROR 
 and Exception.
 I think the reason is the vrouter is not started, But i don't know why. I 
 also do some add nic or remove nic tests when a vrouer is running, and it is 
 normal. 
 so, why?Thanks... 
  



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

[jira] [Commented] (CLOUDSTACK-7476) centos cloudstack-usage script does not always pass along $JAVA_HOME

2014-09-04 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-7476:


GitHub user lsimons opened a pull request:

https://github.com/apache/cloudstack/pull/15

Fix CLOUDSTACK-7476: always pass along $JAVA_HOME

On a secured environment (selinux w/ env_reset enabled in sudoers), the
runuser command that is invoked by the daemon() function does not pass
along environment variables, so $JAVA_HOME is empty, and JSVC falls
back to its default behavior, which may not find java or may not find
the intended java.

This fix simply passes $JAVA_HOME explicitly using the -home argument to
JSVC.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/schubergphilis/cloudstack 
bugfix/CLOUDSTACK-7476

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/15.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #15


commit da9647205aafccee3ae8b60b6ccdee0dcad8c712
Author: Leo Simons lsim...@schubergphilis.com
Date:   2014-09-03T07:32:32Z

Fix CLOUDSTACK-7476: always pass along $JAVA_HOME

On a secured environment (selinux w/ env_reset enabled in sudoers), the
runuser command that is invoked by the daemon() function does not pass
along environment variables, so $JAVA_HOME is empty, and JSVC falls
back to its default behavior, which may not find java or may not find
the intended java.

This fix simply passes $JAVA_HOME explicitly using the -home argument to
JSVC.




 centos cloudstack-usage script does not always pass along $JAVA_HOME
 

 Key: CLOUDSTACK-7476
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7476
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Usage
Affects Versions: 4.5.0
 Environment: secured centos/redhat
Reporter: Leo Simons
 Fix For: 4.5.0


 /etc/init.d/cloudstack-usage finds a $JAVA_HOME and makes sure the 
 environment variable is set, then assumes this variable will be picked up by 
 JSVC.
 However, on a secured environment (selinux w/ env_reset enabled in sudoers), 
 the runuser command that is invoked by the daemon() function does not pass 
 along environment variables, so $JAVA_HOME is empty, and JSVC falls back to 
 its default behavior, which may not find java or may not find the intended 
 java.
 The simple solution is to pass -home to JSVC, passing it on the command line 
 instead of as an environment variable.
 I'll provide a patch.



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

[jira] [Resolved] (CLOUDSTACK-7476) centos cloudstack-usage script does not always pass along $JAVA_HOME

2014-09-04 Thread Leo Simons (JIRA) 

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

Leo Simons resolved CLOUDSTACK-7476.

Resolution: Fixed

https://github.com/apache/cloudstack/pull/15

 centos cloudstack-usage script does not always pass along $JAVA_HOME
 

 Key: CLOUDSTACK-7476
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7476
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Usage
Affects Versions: 4.5.0
 Environment: secured centos/redhat
Reporter: Leo Simons
 Fix For: 4.5.0


 /etc/init.d/cloudstack-usage finds a $JAVA_HOME and makes sure the 
 environment variable is set, then assumes this variable will be picked up by 
 JSVC.
 However, on a secured environment (selinux w/ env_reset enabled in sudoers), 
 the runuser command that is invoked by the daemon() function does not pass 
 along environment variables, so $JAVA_HOME is empty, and JSVC falls back to 
 its default behavior, which may not find java or may not find the intended 
 java.
 The simple solution is to pass -home to JSVC, passing it on the command line 
 instead of as an environment variable.
 I'll provide a patch.



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

[jira] [Resolved] (CLOUDSTACK-6875) test_volumes.TestVolumes.test_09_delete_detached_volume is failing on simulator runs

2014-09-04 Thread Gaurav Aradhye (JIRA) 

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

Gaurav Aradhye resolved CLOUDSTACK-6875.

Resolution: Cannot Reproduce

 test_volumes.TestVolumes.test_09_delete_detached_volume is failing on 
 simulator runs
 

 Key: CLOUDSTACK-6875
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6875
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Reporter: Bharat Kumar
Assignee: Girish Shilamkar

 Error Message
 Job failed: {jobprocstatus : 0, created : u'2014-06-08T20:26:20-0700', cmd : 
 u'org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin', 
 userid : u'36a2cda6-ef83-11e3-a86b-00163e0af42c', jobstatus : 2, jobid : 
 u'b263a941-29b1-4ab8-9c00-7a0d2678b591', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : u'Unexpected 
 exception'}, accountid : u'36a29ade-ef83-11e3-a86b-00163e0af42c'}
   begin captured stdout  -
 === TestName: test_09_delete_detached_volume | Status : EXCEPTION ===
 -  end captured stdout  --
   begin captured logging  
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: STARTED : TC: test_09_delete_detached_volume :::
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: Delete Volume ID: 24051890-92ad-4cee-8ca3-119d278b072a
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: Payload: {'account': u'test-account-TestCreateVolume-N2SRV2', 
 'domainid': u'36a27fb8-ef83-11e3-a86b-00163e0af42c', 'name': 'Test Volume', 
 'zoneid': u'ef5040e4-6e78-433b-a21a-656a7ab31e80', 'apiKey': 
 u'Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ',
  'command': 'createVolume', 'signature': 'O0mZxBTYte8bIWPhtBYKUycq8Yo=', 
 'diskofferingid': u'92b2888e-c624-4042-82b4-632bed2bb38d', 'response': 'json'}
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: Sending GET Cmd : createVolume===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 172.16.88.23
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?account=test-account-TestCreateVolume-N2SRV2domainid=36a27fb8-ef83-11e3-a86b-00163e0af42cname=Test+Volumezoneid=ef5040e4-6e78-433b-a21a-656a7ab31e80apiKey=Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQcommand=createVolumesignature=O0mZxBTYte8bIWPhtBYKUycq8Yo%3Ddiskofferingid=92b2888e-c624-4042-82b4-632bed2bb38dresponse=json
  HTTP/1.1 200 121
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: === Jobid: 2249fb73-7560-4d22-a7f9-dba0507b096e Started ===
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: Payload: {'signature': '8di/lZIPnn9qCgFh0fHVVrH7/8U=', 'apiKey': 
 u'Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ',
  'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
 u'2249fb73-7560-4d22-a7f9-dba0507b096e'}
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: Sending GET Cmd : queryAsyncJobResult===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 172.16.88.23
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?jobid=2249fb73-7560-4d22-a7f9-dba0507b096eapiKey=Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQcommand=queryAsyncJobResultresponse=jsonsignature=8di%2FlZIPnn9qCgFh0fHVVrH7%2F8U%3D
  HTTP/1.1 200 430
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: Response : {jobprocstatus : 0, created : u'2014-06-08T20:26:14-0700', 
 cmd : 
 u'org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin', 
 userid : u'36a2cda6-ef83-11e3-a86b-00163e0af42c', jobstatus : 0, jobid : 
 u'2249fb73-7560-4d22-a7f9-dba0507b096e', jobresultcode : 0, jobinstanceid : 
 u'c936802c-42f3-4ff3-9eb2-dd003517a8ef', jobinstancetype : u'Volume', 
 accountid : u'36a29ade-ef83-11e3-a86b-00163e0af42c'}
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: === JobId:2249fb73-7560-4d22-a7f9-dba0507b096e is Still Processing, 
 Will TimeOut in:3595 
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: Payload: {'signature': '8di/lZIPnn9qCgFh0fHVVrH7/8U=', 'apiKey':

[jira] [Commented] (CLOUDSTACK-7291) LXC: Mgmt server/agent keeps killing systemvms

2014-09-04 Thread Alex Brett (JIRA) 

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

Alex Brett commented on CLOUDSTACK-7291:


OK, I'm obviously seeing something different then (though the symptoms are very 
similar). I'll do a deeper analysis of the logs and file a separate ticket etc 
as necessary once I'm back in the office...

 LXC: Mgmt server/agent keeps killing systemvms
 --

 Key: CLOUDSTACK-7291
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7291
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.3.0, 4.3.1
Reporter: Rohit Yadav
Priority: Blocker
 Fix For: 4.3.1


 Followed installation and setup docs of 4.3, was unable to get LXC to work on 
 Ubuntu 14.04/trusty. The systemvms kept coming up and result from 
 ssvm_check.sh was good and it was able to reach mgmt server /host, even then 
 mgmt server complained that it was unable to contact agent on the systemvm 
 (ping), while the agent would gracefully shutdown the systemvm (by killing 
 them).
 Relevant log:
 2014-08-07 19:52:26,294 INFO  [c.c.u.e.CSExceptionErrorCode] 
 (secstorage-1:ctx-fc57ef43) Could not find exception: 
 com.cloud.exception.OperationTimedoutException in error code list for 
 exceptions
 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host 
 Host[-1-Routing]
 2014-08-07 19:52:26,295 DEBUG [c.c.a.m.AgentAttache] 
 (consoleproxy-1:ctx-e123fa9c) Seq 1-51249205: Cancelling.
 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host 
 Host[-1-Routing]
 2014-08-07 19:52:26,303 DEBUG [c.c.h.Status] (AgentTaskPool-13:ctx-0b35e679) 
 Transition:[Resource state = Enabled, Agent event = ShutdownRequested, Host 
 id = 1, name = bluebox1.bhaisaab.org]
 2014-08-07 19:52:26,311 DEBUG [c.c.h.HighAvailabilityManagerImpl] 
 (secstorage-1:ctx-fc57ef43) Scheduled 
 HAWork[12-CheckStop-2-Starting-Scheduled]
 2014-08-07 19:52:26,314 WARN  [c.c.s.s.SecondaryStorageManagerImpl] 
 (secstorage-1:ctx-fc57ef43) Exception while trying to start secondary storage 
 vm
 com.cloud.exception.AgentUnavailableException: Resource [Host:1] is 
 unreachable: Host 1: Unable to start s-2-VM
 ---at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1051)
 ---at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761)
 ---at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745)
 ---at 
 com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261)
 ---at 
 com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:694)
 ---at 
 com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1278)
 ---at 
 com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123)
 ---at 
 com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50)
 ---at 
 com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111) 
 ...
 ...
 ...
 Caused by: com.cloud.exception.OperationTimedoutException: Commands 51249206 
 to Host 1 timed out after 3600
 ---at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:439)   
  
 ---at 
 com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:394)
 ---at 
 com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:920)
 ---at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:989)
 ---... 24 more   
  



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

[jira] [Closed] (CLOUDSTACK-6875) test_volumes.TestVolumes.test_09_delete_detached_volume is failing on simulator runs

2014-09-04 Thread Gaurav Aradhye (JIRA) 

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

Gaurav Aradhye closed CLOUDSTACK-6875.
--
Assignee: (was: Girish Shilamkar)

The test case is passing in the CI simulator runs and this issue is not seen.
Closing this.

 test_volumes.TestVolumes.test_09_delete_detached_volume is failing on 
 simulator runs
 

 Key: CLOUDSTACK-6875
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6875
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Reporter: Bharat Kumar

 Error Message
 Job failed: {jobprocstatus : 0, created : u'2014-06-08T20:26:20-0700', cmd : 
 u'org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin', 
 userid : u'36a2cda6-ef83-11e3-a86b-00163e0af42c', jobstatus : 2, jobid : 
 u'b263a941-29b1-4ab8-9c00-7a0d2678b591', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : u'Unexpected 
 exception'}, accountid : u'36a29ade-ef83-11e3-a86b-00163e0af42c'}
   begin captured stdout  -
 === TestName: test_09_delete_detached_volume | Status : EXCEPTION ===
 -  end captured stdout  --
   begin captured logging  
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: STARTED : TC: test_09_delete_detached_volume :::
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: Delete Volume ID: 24051890-92ad-4cee-8ca3-119d278b072a
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: Payload: {'account': u'test-account-TestCreateVolume-N2SRV2', 
 'domainid': u'36a27fb8-ef83-11e3-a86b-00163e0af42c', 'name': 'Test Volume', 
 'zoneid': u'ef5040e4-6e78-433b-a21a-656a7ab31e80', 'apiKey': 
 u'Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ',
  'command': 'createVolume', 'signature': 'O0mZxBTYte8bIWPhtBYKUycq8Yo=', 
 'diskofferingid': u'92b2888e-c624-4042-82b4-632bed2bb38d', 'response': 'json'}
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: Sending GET Cmd : createVolume===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 172.16.88.23
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?account=test-account-TestCreateVolume-N2SRV2domainid=36a27fb8-ef83-11e3-a86b-00163e0af42cname=Test+Volumezoneid=ef5040e4-6e78-433b-a21a-656a7ab31e80apiKey=Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQcommand=createVolumesignature=O0mZxBTYte8bIWPhtBYKUycq8Yo%3Ddiskofferingid=92b2888e-c624-4042-82b4-632bed2bb38dresponse=json
  HTTP/1.1 200 121
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: === Jobid: 2249fb73-7560-4d22-a7f9-dba0507b096e Started ===
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: Payload: {'signature': '8di/lZIPnn9qCgFh0fHVVrH7/8U=', 'apiKey': 
 u'Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ',
  'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
 u'2249fb73-7560-4d22-a7f9-dba0507b096e'}
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: Sending GET Cmd : queryAsyncJobResult===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 172.16.88.23
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?jobid=2249fb73-7560-4d22-a7f9-dba0507b096eapiKey=Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQcommand=queryAsyncJobResultresponse=jsonsignature=8di%2FlZIPnn9qCgFh0fHVVrH7%2F8U%3D
  HTTP/1.1 200 430
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: Response : {jobprocstatus : 0, created : u'2014-06-08T20:26:14-0700', 
 cmd : 
 u'org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin', 
 userid : u'36a2cda6-ef83-11e3-a86b-00163e0af42c', jobstatus : 0, jobid : 
 u'2249fb73-7560-4d22-a7f9-dba0507b096e', jobresultcode : 0, jobinstanceid : 
 u'c936802c-42f3-4ff3-9eb2-dd003517a8ef', jobinstancetype : u'Volume', 
 accountid : u'36a29ade-ef83-11e3-a86b-00163e0af42c'}
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: === JobId:2249fb73-7560-4d22-a7f9-dba0507b096e is Still Processing, 
 Will TimeOut in:3595 
 test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes): 
 DEBUG: Payload: {'signature': '8di/lZIPnn9qCgFh0fHVVrH7/8U=',

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

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit 7a57d780bc1eb7c5799856f710a9f86965aa9c7a in cloudstack's branch 
refs/heads/4.4 from [~imduffy15]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7a57d78 ]

[CLOUDSTACK-6115] Investigate the use of TravisCI for CloudStack integration 
testing

(cherry picked from commit 26069aa3776ea4b634fb9d614062caa595bc0fa0)


 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
Assignee: Ian Duffy
 Fix For: 4.5.0, 4.3.1


 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.3.4#6332)

[jira] [Closed] (CLOUDSTACK-6906) [Automation] volume resize test cases failing in BVT

2014-09-04 Thread Gaurav Aradhye (JIRA) 

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

Gaurav Aradhye closed CLOUDSTACK-6906.
--
Resolution: Duplicate

Duplicate issue. 

 [Automation] volume resize test cases failing in BVT 
 -

 Key: CLOUDSTACK-6906
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6906
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
Assignee: Girish Shilamkar
Priority: Critical
 Fix For: 4.4.0, 4.5.0






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

[jira] [Commented] (CLOUDSTACK-6942) LXC: optimize template copy to primary

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

Fixed CLOUDSTACK-6942: LXC: optimize template copy to primary

saving LXC template as tar to primary and extracting it only when
required.
This would improve the template copy time.

Reviewed By: Kishan Kavala


 LXC: optimize template copy to primary
 --

 Key: CLOUDSTACK-6942
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6942
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller
Reporter: Rajani Karuturi
Assignee: Rajani Karuturi
Priority: Critical
 Fix For: 4.5.0


 most of the time spent when launching a container is in template copy and 
 extraction. optimize it so that the container launch can be faster.



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

[jira] [Resolved] (CLOUDSTACK-6966) Attach volume causes unexpected exception intermittently

2014-09-04 Thread Gaurav Aradhye (JIRA) 

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

Gaurav Aradhye resolved CLOUDSTACK-6966.

Resolution: Cannot Reproduce

The test case has passed the recent builds on simulator and the issue is not 
seen. Santhosh also could not reproduce this. Closing the issue as Not 
reproducible.

 Attach volume causes unexpected exception intermittently
 

 Key: CLOUDSTACK-6966
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6966
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Girish Shilamkar
Assignee: Santhosh Kumar Edukulla

 test_09_delete_detached_volume test fails sometimes while attaching the 
 volume. Upon investigating it was found that unexpected exception is thrown 
 by management server. 
 Log:
 2014-06-19 07:43:09,198 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-40:ctx-c775dc91 job-7728) Unexpected exception while 
 executing org.apache.cloudstack.api.
 command.admin.volume.AttachVolumeCmdByAdmin
 java.lang.RuntimeException: Unexpected exception
 at 
 com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1045)
 at sun.reflect.GeneratedMethodAccessor669.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.$Proxy182.attachVolumeToVM(Unknown Source)
 at 
 org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin.execute(AttachVolumeCmdByAdmin.java:38)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)
 Caused by: java.lang.RuntimeException: Job failed due to exception Failed to 
 attach volume Test Volume to VM VM-43cf6765-bf73-4c3f-a1b3-24214d7dee93; 
 org.libvirt.Libvi
 rtException: internal error unable to execute QEMU command 
 '__com.redhat_drive_add': Duplicate ID 'drive-virtio-disk1' for drive
 ... 25 more
 2014-06-19 07:43:09,199 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-40:ctx-c775dc91 job-7728) Complete async job-7728, 
 jobStatus: FAILED, resultCode: 530
 , result: org.apache.cloudstack.api.response.ExceptionResponse/null/
 {uuidList:[],errorcode:530,errortext:Unexpected exception}
 2014-06-19 07:43:09,199 INFO [o.a.c.f.j.i.AsyncJobMonitor] 
 (Work-Job-Executor-80:ctx-830fcb84 job-7728/job-7729) Remove job-7729 from 
 job monitoring
 2014-06-19 07:43:09,203 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-40:ctx-c775dc91 job-7728) Done executing 
 org.apache.cloudstack.api.command.admin.volu
 me.AttachVolumeCmdByAdmin for job-7728
 2014-06-19 07:43:09,207 INFO [o.a.c.f.j.i.AsyncJobMonitor] 
 (API-Job-Executor-40:ctx-c775dc91 job-7728) Remove job-7728 from job 
 monitoring
 2014-06-19 07:43:09,655 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-6:null) SeqA 9-9704: Processing Seq 9-9704: { Cmd , 
 MgmtId:

[jira] [Updated] (CLOUDSTACK-7375) RBD not available under list of protocols for primary storage during zone creation

2014-09-04 Thread Rajani Karuturi (JIRA) 

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

Rajani Karuturi updated CLOUDSTACK-7375:

Priority: Major  (was: Critical)

 RBD not available under list of protocols for primary storage during zone 
 creation
 --

 Key: CLOUDSTACK-7375
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7375
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Storage Controller, UI
Affects Versions: 4.5.0
Reporter: Pavan Kumar Bandarupally
Assignee: Rajani Karuturi
 Fix For: 4.5.0

 Attachments: screenshot-1.jpg


 Currently cloudstack supports CEPH storage as primary store without a 
 requirement for another NFS store before adding CEPH storage. But during zone 
 creation, we don't see RBD under protocol list for primary storage addition 
 wizard.
 Please see attached image.
 Expected:
 -
 There should be RBD protocol so that user can add a CEPH primary store during 
 zone creation.



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

[jira] [Resolved] (CLOUDSTACK-6942) LXC: optimize template copy to primary

2014-09-04 Thread Rajani Karuturi (JIRA) 

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

Rajani Karuturi resolved CLOUDSTACK-6942.
-
Resolution: Fixed

 LXC: optimize template copy to primary
 --

 Key: CLOUDSTACK-6942
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6942
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller
Reporter: Rajani Karuturi
Assignee: Rajani Karuturi
Priority: Critical
 Fix For: 4.5.0


 most of the time spent when launching a container is in template copy and 
 extraction. optimize it so that the container launch can be faster.



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

[jira] [Updated] (CLOUDSTACK-7375) RBD not available under list of protocols for primary storage during zone creation

2014-09-04 Thread Rajani Karuturi (JIRA) 

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

Rajani Karuturi updated CLOUDSTACK-7375:

Assignee: (was: Rajani Karuturi)

 RBD not available under list of protocols for primary storage during zone 
 creation
 --

 Key: CLOUDSTACK-7375
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7375
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Storage Controller, UI
Affects Versions: 4.5.0
Reporter: Pavan Kumar Bandarupally
 Fix For: 4.5.0

 Attachments: screenshot-1.jpg


 Currently cloudstack supports CEPH storage as primary store without a 
 requirement for another NFS store before adding CEPH storage. But during zone 
 creation, we don't see RBD under protocol list for primary storage addition 
 wizard.
 Please see attached image.
 Expected:
 -
 There should be RBD protocol so that user can add a CEPH primary store during 
 zone creation.



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

[jira] [Assigned] (CLOUDSTACK-7390) [Automation] Fix the script test_bugs.py - Invalid Parameters

2014-09-04 Thread Srikanteswararao Talluri (JIRA) 

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

Srikanteswararao Talluri reassigned CLOUDSTACK-7390:


Assignee: Srikanteswararao Talluri  (was: Gaurav Aradhye)

 [Automation] Fix the script test_bugs.py - Invalid Parameters
 ---

 Key: CLOUDSTACK-7390
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7390
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 Script is at: component/maint/.
 {code}
 @attr(tags=[advanced, basic])
 @attr(required_hardware=false)
 @attr(configuration='apply.allocation.algorithm.to.pods')
 def test_es_47_list_os_types_win_2012(self):
 
 @Desc: Test VM creation while apply.allocation.algorithm.to.pods is 
 set to true
 @Reference: https://issues.apache.org/jira/browse/CLOUDSTACK-4947
 @Steps:
 Step1: register windows 2012 VM template as windows 8 template
 Step2: deploy a VM with windows2012 template and  Verify that VM 
 creation is successful
  
 # register windows 2012 VM template as windows 8 template
 self.win2012_template = Template.register(
 self.apiClient,
 self.services[win2012template],
 zoneid=self.zone.id,
 account=self.account.name,
 domainid=self.domain.id,
 hypervisor=self.hypervisor
 )
 # Wait for template to download
 self.win2012_template.download(self.apiClient)
 self.cleanup.append(self.win2012_template)
 # Wait for template status to be changed across
 time.sleep(60)
 # Deploy
 self.debug(Deploying win 2012 VM in account: %s % self.account.name)
 self.services[virtual_machine][displayname] = win2012
 self.services[virtual_machine][zoneid] = self.zone.id
 self.services[virtual_machine][template] = 
 self.win2012_template.id
 vm1 = VirtualMachine.create(
 self.apiClient,
 self.services[virtual_machine2],
 accountid=self.account.name,
 domainid=self.account.domainid,
 serviceofferingid=self.service_offering.id,
 )
 self.cleanup.append(vm1)
 # Verify VM state
 self.assertEqual(
 vm1.state,
 'Running',
 Check VM state is Running or not
 )
 return
   

 {code}
 
 Client Error Information:
 
 test_es_47_list_os_types_win_2012 
 (integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: 
 Sending GET Cmd : listTemplates===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.135.39
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?templatefilter=selfapiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwzoneid=f2acfe0c-c8c8-4353-8f97-a3e0f14d6357command=listTemplatessignature=LjryRXT0OpAYRm%2BuM5slT8BkAh4%3Did=1ee5bf28-5cbe-41e4-ba11-0418ecda39c4response=json
  HTTP/1.1 200 847
 test_es_47_list_os_types_win_2012 
 (integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: Response : 
 [{domain : u'ROOT', domainid : u'9d7d4d5c-281e-11e4-b06a-d2bc9de3652e', 
 ostypename : u'Windows 8 (64-bit)', zoneid : 
 u'f2acfe0c-c8c8-4353-8f97-a3e0f14d6357', displaytext : u'win2012', ostypeid : 
 u'9d9979e6-281e-11e4-b06a-d2bc9de3652e', passwordenabled : False, id : 
 u'1ee5bf28-5cbe-41e4-ba11-0418ecda39c4', size : 34359738368, isready : True, 
 format : u'OVA', templatetype : u'USER', details : {hypervisortoolsversion : 
 u'xenserver61'}, zonename : u'XenRT-Zone-0', status : u'Download Complete', 
 isdynamicallyscalable : False, tags : [], isfeatured : False, sshkeyenabled : 
 False, isextractable : False, crossZones : False, account : 
 u'test-a-Test42xBugsMgmtSvr-BJ4H02', name : u'win2012-S1SJ8X', created : 
 u'2014-08-20T13:24:49+', hypervisor : u'XenServer', ispublic : False, 
 checksum : u'b31fec1e736b8bc27db9d0f6740c6622'}]
 test_es_47_list_os_types_win_2012 
 (integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: Deploying

[jira] [Assigned] (CLOUDSTACK-7389) [Automation] Fix the script test_bugs.py - Unable to find Ostype is required for registering template

2014-09-04 Thread Srikanteswararao Talluri (JIRA) 

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

Srikanteswararao Talluri reassigned CLOUDSTACK-7389:


Assignee: Srikanteswararao Talluri  (was: Gaurav Aradhye)

 [Automation] Fix the script test_bugs.py - Unable to find Ostype is 
 required for registering template
 ---

 Key: CLOUDSTACK-7389
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7389
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 Script is at: component/maint/.
 {code}
 @attr(required_hardware=false)
 @attr(storage=s3)
 def test_es_1863_register_template_s3_domain_admin_user(self):
 
 @Desc: Test whether cloudstack allows Domain admin or user to 
 register a template using
 S3/Swift object store.
 @Steps:
 Step1: create a Domain and users in it.
 Step2: Register a template as Domain admin.
 Step3: Register a template as Domain user.
 Step4: Template should be registered successfully.
 
 # Step1: create a Domain and users in it.
 self.newdomain = Domain.create(self.apiClient,
self.services[domain])
 #create account in the domain
 self.account_domain = Account.create(
 self.apiClient,
 self.services[account],
 domainid=self.newdomain.id
 )
 self.cleanup.append(self.account_domain)
 self.cleanup.append(self.newdomain)
 # Getting authentication for user in newly created Account in domain
 self.domain_user = self.account_domain.user[0]
 self.domain_userapiclient = 
 self.testClient.getUserApiClient(self.domain_user.username, 
 self.newdomain.name)
 # Step2: Register a template as Domain admin.
 self.domain_template = Template.register(
 self.apiClient,
 self.services[templateregister],
 zoneid=self.zone.id,
 account=self.account_domain.name,
 domainid=self.newdomain.id,
 hypervisor=self.hypervisor
 )
 # Wait for template to download
 self.domain_template.download(self.api_client)
 # Wait for template status to be changed across
 time.sleep(60)
 # Step3: Register a template as Domain user.
 self.domain_user_template = Template.register(
 self.domain_userapiclient,
 self.services[templateregister],
 zoneid=self.zone.id,
 account=self.account_domain.name,
 domainid=self.newdomain.id,
 hypervisor=self.hypervisor
 )
 {code}
 *Error Message*
 Unable to find Ostype is required for registering template
   begin captured stdout  -
 === TestName: test_es_1863_register_template_s3_domain_admin_user | Status : 
 EXCEPTION ===
 -  end captured stdout  --



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

[jira] [Commented] (CLOUDSTACK-7389) [Automation] Fix the script test_bugs.py - Unable to find Ostype is required for registering template

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit aa64d8b3e7222c9b849f28efcae4168a01da679b in cloudstack's branch 
refs/heads/master from SrikanteswaraRao Talluri
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aa64d8b ]

CLOUDSTACK-7389: fix for the script bugs CLOUDSTACK-7389, CLOUDSTACK-7390 and 
few
other fixes.


 [Automation] Fix the script test_bugs.py - Unable to find Ostype is 
 required for registering template
 ---

 Key: CLOUDSTACK-7389
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7389
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 Script is at: component/maint/.
 {code}
 @attr(required_hardware=false)
 @attr(storage=s3)
 def test_es_1863_register_template_s3_domain_admin_user(self):
 
 @Desc: Test whether cloudstack allows Domain admin or user to 
 register a template using
 S3/Swift object store.
 @Steps:
 Step1: create a Domain and users in it.
 Step2: Register a template as Domain admin.
 Step3: Register a template as Domain user.
 Step4: Template should be registered successfully.
 
 # Step1: create a Domain and users in it.
 self.newdomain = Domain.create(self.apiClient,
self.services[domain])
 #create account in the domain
 self.account_domain = Account.create(
 self.apiClient,
 self.services[account],
 domainid=self.newdomain.id
 )
 self.cleanup.append(self.account_domain)
 self.cleanup.append(self.newdomain)
 # Getting authentication for user in newly created Account in domain
 self.domain_user = self.account_domain.user[0]
 self.domain_userapiclient = 
 self.testClient.getUserApiClient(self.domain_user.username, 
 self.newdomain.name)
 # Step2: Register a template as Domain admin.
 self.domain_template = Template.register(
 self.apiClient,
 self.services[templateregister],
 zoneid=self.zone.id,
 account=self.account_domain.name,
 domainid=self.newdomain.id,
 hypervisor=self.hypervisor
 )
 # Wait for template to download
 self.domain_template.download(self.api_client)
 # Wait for template status to be changed across
 time.sleep(60)
 # Step3: Register a template as Domain user.
 self.domain_user_template = Template.register(
 self.domain_userapiclient,
 self.services[templateregister],
 zoneid=self.zone.id,
 account=self.account_domain.name,
 domainid=self.newdomain.id,
 hypervisor=self.hypervisor
 )
 {code}
 *Error Message*
 Unable to find Ostype is required for registering template
   begin captured stdout  -
 === TestName: test_es_1863_register_template_s3_domain_admin_user | Status : 
 EXCEPTION ===
 -  end captured stdout  --



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

[jira] [Resolved] (CLOUDSTACK-7389) [Automation] Fix the script test_bugs.py - Unable to find Ostype is required for registering template

2014-09-04 Thread Srikanteswararao Talluri (JIRA) 

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

Srikanteswararao Talluri resolved CLOUDSTACK-7389.
--
Resolution: Fixed

 [Automation] Fix the script test_bugs.py - Unable to find Ostype is 
 required for registering template
 ---

 Key: CLOUDSTACK-7389
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7389
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 Script is at: component/maint/.
 {code}
 @attr(required_hardware=false)
 @attr(storage=s3)
 def test_es_1863_register_template_s3_domain_admin_user(self):
 
 @Desc: Test whether cloudstack allows Domain admin or user to 
 register a template using
 S3/Swift object store.
 @Steps:
 Step1: create a Domain and users in it.
 Step2: Register a template as Domain admin.
 Step3: Register a template as Domain user.
 Step4: Template should be registered successfully.
 
 # Step1: create a Domain and users in it.
 self.newdomain = Domain.create(self.apiClient,
self.services[domain])
 #create account in the domain
 self.account_domain = Account.create(
 self.apiClient,
 self.services[account],
 domainid=self.newdomain.id
 )
 self.cleanup.append(self.account_domain)
 self.cleanup.append(self.newdomain)
 # Getting authentication for user in newly created Account in domain
 self.domain_user = self.account_domain.user[0]
 self.domain_userapiclient = 
 self.testClient.getUserApiClient(self.domain_user.username, 
 self.newdomain.name)
 # Step2: Register a template as Domain admin.
 self.domain_template = Template.register(
 self.apiClient,
 self.services[templateregister],
 zoneid=self.zone.id,
 account=self.account_domain.name,
 domainid=self.newdomain.id,
 hypervisor=self.hypervisor
 )
 # Wait for template to download
 self.domain_template.download(self.api_client)
 # Wait for template status to be changed across
 time.sleep(60)
 # Step3: Register a template as Domain user.
 self.domain_user_template = Template.register(
 self.domain_userapiclient,
 self.services[templateregister],
 zoneid=self.zone.id,
 account=self.account_domain.name,
 domainid=self.newdomain.id,
 hypervisor=self.hypervisor
 )
 {code}
 *Error Message*
 Unable to find Ostype is required for registering template
   begin captured stdout  -
 === TestName: test_es_1863_register_template_s3_domain_admin_user | Status : 
 EXCEPTION ===
 -  end captured stdout  --



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

[jira] [Commented] (CLOUDSTACK-7390) [Automation] Fix the script test_bugs.py - Invalid Parameters

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit aa64d8b3e7222c9b849f28efcae4168a01da679b in cloudstack's branch 
refs/heads/master from SrikanteswaraRao Talluri
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aa64d8b ]

CLOUDSTACK-7389: fix for the script bugs CLOUDSTACK-7389, CLOUDSTACK-7390 and 
few
other fixes.


 [Automation] Fix the script test_bugs.py - Invalid Parameters
 ---

 Key: CLOUDSTACK-7390
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7390
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 Script is at: component/maint/.
 {code}
 @attr(tags=[advanced, basic])
 @attr(required_hardware=false)
 @attr(configuration='apply.allocation.algorithm.to.pods')
 def test_es_47_list_os_types_win_2012(self):
 
 @Desc: Test VM creation while apply.allocation.algorithm.to.pods is 
 set to true
 @Reference: https://issues.apache.org/jira/browse/CLOUDSTACK-4947
 @Steps:
 Step1: register windows 2012 VM template as windows 8 template
 Step2: deploy a VM with windows2012 template and  Verify that VM 
 creation is successful
  
 # register windows 2012 VM template as windows 8 template
 self.win2012_template = Template.register(
 self.apiClient,
 self.services[win2012template],
 zoneid=self.zone.id,
 account=self.account.name,
 domainid=self.domain.id,
 hypervisor=self.hypervisor
 )
 # Wait for template to download
 self.win2012_template.download(self.apiClient)
 self.cleanup.append(self.win2012_template)
 # Wait for template status to be changed across
 time.sleep(60)
 # Deploy
 self.debug(Deploying win 2012 VM in account: %s % self.account.name)
 self.services[virtual_machine][displayname] = win2012
 self.services[virtual_machine][zoneid] = self.zone.id
 self.services[virtual_machine][template] = 
 self.win2012_template.id
 vm1 = VirtualMachine.create(
 self.apiClient,
 self.services[virtual_machine2],
 accountid=self.account.name,
 domainid=self.account.domainid,
 serviceofferingid=self.service_offering.id,
 )
 self.cleanup.append(vm1)
 # Verify VM state
 self.assertEqual(
 vm1.state,
 'Running',
 Check VM state is Running or not
 )
 return
   

 {code}
 
 Client Error Information:
 
 test_es_47_list_os_types_win_2012 
 (integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: 
 Sending GET Cmd : listTemplates===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.135.39
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?templatefilter=selfapiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwzoneid=f2acfe0c-c8c8-4353-8f97-a3e0f14d6357command=listTemplatessignature=LjryRXT0OpAYRm%2BuM5slT8BkAh4%3Did=1ee5bf28-5cbe-41e4-ba11-0418ecda39c4response=json
  HTTP/1.1 200 847
 test_es_47_list_os_types_win_2012 
 (integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: Response : 
 [{domain : u'ROOT', domainid : u'9d7d4d5c-281e-11e4-b06a-d2bc9de3652e', 
 ostypename : u'Windows 8 (64-bit)', zoneid : 
 u'f2acfe0c-c8c8-4353-8f97-a3e0f14d6357', displaytext : u'win2012', ostypeid : 
 u'9d9979e6-281e-11e4-b06a-d2bc9de3652e', passwordenabled : False, id : 
 u'1ee5bf28-5cbe-41e4-ba11-0418ecda39c4', size : 34359738368, isready : True, 
 format : u'OVA', templatetype : u'USER', details : {hypervisortoolsversion : 
 u'xenserver61'}, zonename : u'XenRT-Zone-0', status : u'Download Complete', 
 isdynamicallyscalable : False, tags : [], isfeatured : False, sshkeyenabled : 
 False, isextractable : False, crossZones : False, account :

[jira] [Commented] (CLOUDSTACK-7389) [Automation] Fix the script test_bugs.py - Unable to find Ostype is required for registering template

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit aa64d8b3e7222c9b849f28efcae4168a01da679b in cloudstack's branch 
refs/heads/master from SrikanteswaraRao Talluri
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aa64d8b ]

CLOUDSTACK-7389: fix for the script bugs CLOUDSTACK-7389, CLOUDSTACK-7390 and 
few
other fixes.


 [Automation] Fix the script test_bugs.py - Unable to find Ostype is 
 required for registering template
 ---

 Key: CLOUDSTACK-7389
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7389
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 Script is at: component/maint/.
 {code}
 @attr(required_hardware=false)
 @attr(storage=s3)
 def test_es_1863_register_template_s3_domain_admin_user(self):
 
 @Desc: Test whether cloudstack allows Domain admin or user to 
 register a template using
 S3/Swift object store.
 @Steps:
 Step1: create a Domain and users in it.
 Step2: Register a template as Domain admin.
 Step3: Register a template as Domain user.
 Step4: Template should be registered successfully.
 
 # Step1: create a Domain and users in it.
 self.newdomain = Domain.create(self.apiClient,
self.services[domain])
 #create account in the domain
 self.account_domain = Account.create(
 self.apiClient,
 self.services[account],
 domainid=self.newdomain.id
 )
 self.cleanup.append(self.account_domain)
 self.cleanup.append(self.newdomain)
 # Getting authentication for user in newly created Account in domain
 self.domain_user = self.account_domain.user[0]
 self.domain_userapiclient = 
 self.testClient.getUserApiClient(self.domain_user.username, 
 self.newdomain.name)
 # Step2: Register a template as Domain admin.
 self.domain_template = Template.register(
 self.apiClient,
 self.services[templateregister],
 zoneid=self.zone.id,
 account=self.account_domain.name,
 domainid=self.newdomain.id,
 hypervisor=self.hypervisor
 )
 # Wait for template to download
 self.domain_template.download(self.api_client)
 # Wait for template status to be changed across
 time.sleep(60)
 # Step3: Register a template as Domain user.
 self.domain_user_template = Template.register(
 self.domain_userapiclient,
 self.services[templateregister],
 zoneid=self.zone.id,
 account=self.account_domain.name,
 domainid=self.newdomain.id,
 hypervisor=self.hypervisor
 )
 {code}
 *Error Message*
 Unable to find Ostype is required for registering template
   begin captured stdout  -
 === TestName: test_es_1863_register_template_s3_domain_admin_user | Status : 
 EXCEPTION ===
 -  end captured stdout  --



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

[jira] [Resolved] (CLOUDSTACK-7390) [Automation] Fix the script test_bugs.py - Invalid Parameters

2014-09-04 Thread Srikanteswararao Talluri (JIRA) 

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

Srikanteswararao Talluri resolved CLOUDSTACK-7390.
--
Resolution: Fixed

 [Automation] Fix the script test_bugs.py - Invalid Parameters
 ---

 Key: CLOUDSTACK-7390
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7390
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 Script is at: component/maint/.
 {code}
 @attr(tags=[advanced, basic])
 @attr(required_hardware=false)
 @attr(configuration='apply.allocation.algorithm.to.pods')
 def test_es_47_list_os_types_win_2012(self):
 
 @Desc: Test VM creation while apply.allocation.algorithm.to.pods is 
 set to true
 @Reference: https://issues.apache.org/jira/browse/CLOUDSTACK-4947
 @Steps:
 Step1: register windows 2012 VM template as windows 8 template
 Step2: deploy a VM with windows2012 template and  Verify that VM 
 creation is successful
  
 # register windows 2012 VM template as windows 8 template
 self.win2012_template = Template.register(
 self.apiClient,
 self.services[win2012template],
 zoneid=self.zone.id,
 account=self.account.name,
 domainid=self.domain.id,
 hypervisor=self.hypervisor
 )
 # Wait for template to download
 self.win2012_template.download(self.apiClient)
 self.cleanup.append(self.win2012_template)
 # Wait for template status to be changed across
 time.sleep(60)
 # Deploy
 self.debug(Deploying win 2012 VM in account: %s % self.account.name)
 self.services[virtual_machine][displayname] = win2012
 self.services[virtual_machine][zoneid] = self.zone.id
 self.services[virtual_machine][template] = 
 self.win2012_template.id
 vm1 = VirtualMachine.create(
 self.apiClient,
 self.services[virtual_machine2],
 accountid=self.account.name,
 domainid=self.account.domainid,
 serviceofferingid=self.service_offering.id,
 )
 self.cleanup.append(vm1)
 # Verify VM state
 self.assertEqual(
 vm1.state,
 'Running',
 Check VM state is Running or not
 )
 return
   

 {code}
 
 Client Error Information:
 
 test_es_47_list_os_types_win_2012 
 (integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: 
 Sending GET Cmd : listTemplates===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.135.39
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?templatefilter=selfapiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwzoneid=f2acfe0c-c8c8-4353-8f97-a3e0f14d6357command=listTemplatessignature=LjryRXT0OpAYRm%2BuM5slT8BkAh4%3Did=1ee5bf28-5cbe-41e4-ba11-0418ecda39c4response=json
  HTTP/1.1 200 847
 test_es_47_list_os_types_win_2012 
 (integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: Response : 
 [{domain : u'ROOT', domainid : u'9d7d4d5c-281e-11e4-b06a-d2bc9de3652e', 
 ostypename : u'Windows 8 (64-bit)', zoneid : 
 u'f2acfe0c-c8c8-4353-8f97-a3e0f14d6357', displaytext : u'win2012', ostypeid : 
 u'9d9979e6-281e-11e4-b06a-d2bc9de3652e', passwordenabled : False, id : 
 u'1ee5bf28-5cbe-41e4-ba11-0418ecda39c4', size : 34359738368, isready : True, 
 format : u'OVA', templatetype : u'USER', details : {hypervisortoolsversion : 
 u'xenserver61'}, zonename : u'XenRT-Zone-0', status : u'Download Complete', 
 isdynamicallyscalable : False, tags : [], isfeatured : False, sshkeyenabled : 
 False, isextractable : False, crossZones : False, account : 
 u'test-a-Test42xBugsMgmtSvr-BJ4H02', name : u'win2012-S1SJ8X', created : 
 u'2014-08-20T13:24:49+', hypervisor : u'XenServer', ispublic : False, 
 checksum : u'b31fec1e736b8bc27db9d0f6740c6622'}]
 test_es_47_list_os_types_win_2012 
 (integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: Deploying 
 win 2012 VM in account:

[jira] [Assigned] (CLOUDSTACK-7388) [Automation] Fix the script test_redundant_router.py - Script is hardcoded to use password as Host's password

2014-09-04 Thread Srikanteswararao Talluri (JIRA) 

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

Srikanteswararao Talluri reassigned CLOUDSTACK-7388:


Assignee: Srikanteswararao Talluri  (was: Gaurav Aradhye)

 [Automation] Fix the script test_redundant_router.py - Script is hardcoded 
 to use password as Host's password
 -

 Key: CLOUDSTACK-7388
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7388
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 Script is at: component/maint/.
 Observe the below code in test_redundant_router.py script:
 {code}
 ...
 .
 .
 },
 host: {
  username: root,
  password: password,
  publicport: 22,
 },
 network: {
 .
 .
 .
 .
 @attr(tags=[advanced, advancedns, ssh])
 def test_redundantVR_internals(self):
 Test redundant router internals
 
 .
 .
 .
 else:
 result = get_process_status(
 backup_host.ipaddress,
 self.services['host'][publicport],
 self.services['host'][username],
 self.services['host'][password],
 backup_router.linklocalip,
 'ip addr show eth2',
 )
 res = str(result)
 .
 .
 .
 {code}
 The above code should be changed to use the host information from 
 configuration file outside this script.



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

[jira] [Commented] (CLOUDSTACK-7388) [Automation] Fix the script test_redundant_router.py - Script is hardcoded to use password as Host's password

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit 3d369de6fe3bc415c5bda5dffecc79e02ca58993 in cloudstack's branch 
refs/heads/master from SrikanteswaraRao Talluri
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3d369de ]

CLOUDSTACK-7388: removed host credentials in the services dict.


 [Automation] Fix the script test_redundant_router.py - Script is hardcoded 
 to use password as Host's password
 -

 Key: CLOUDSTACK-7388
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7388
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 Script is at: component/maint/.
 Observe the below code in test_redundant_router.py script:
 {code}
 ...
 .
 .
 },
 host: {
  username: root,
  password: password,
  publicport: 22,
 },
 network: {
 .
 .
 .
 .
 @attr(tags=[advanced, advancedns, ssh])
 def test_redundantVR_internals(self):
 Test redundant router internals
 
 .
 .
 .
 else:
 result = get_process_status(
 backup_host.ipaddress,
 self.services['host'][publicport],
 self.services['host'][username],
 self.services['host'][password],
 backup_router.linklocalip,
 'ip addr show eth2',
 )
 res = str(result)
 .
 .
 .
 {code}
 The above code should be changed to use the host information from 
 configuration file outside this script.



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

[jira] [Resolved] (CLOUDSTACK-7388) [Automation] Fix the script test_redundant_router.py - Script is hardcoded to use password as Host's password

2014-09-04 Thread Srikanteswararao Talluri (JIRA) 

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

Srikanteswararao Talluri resolved CLOUDSTACK-7388.
--
Resolution: Fixed

 [Automation] Fix the script test_redundant_router.py - Script is hardcoded 
 to use password as Host's password
 -

 Key: CLOUDSTACK-7388
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7388
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 Script is at: component/maint/.
 Observe the below code in test_redundant_router.py script:
 {code}
 ...
 .
 .
 },
 host: {
  username: root,
  password: password,
  publicport: 22,
 },
 network: {
 .
 .
 .
 .
 @attr(tags=[advanced, advancedns, ssh])
 def test_redundantVR_internals(self):
 Test redundant router internals
 
 .
 .
 .
 else:
 result = get_process_status(
 backup_host.ipaddress,
 self.services['host'][publicport],
 self.services['host'][username],
 self.services['host'][password],
 backup_router.linklocalip,
 'ip addr show eth2',
 )
 res = str(result)
 .
 .
 .
 {code}
 The above code should be changed to use the host information from 
 configuration file outside this script.



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

[jira] [Assigned] (CLOUDSTACK-7431) [Automation] Fix the script test_ldap.py - Move the Ldap configuration information to test_data.py

2014-09-04 Thread Srikanteswararao Talluri (JIRA) 

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

Srikanteswararao Talluri reassigned CLOUDSTACK-7431:


Assignee: Srikanteswararao Talluri

 [Automation] Fix the script test_ldap.py - Move the Ldap configuration 
 information to test_data.py
 

 Key: CLOUDSTACK-7431
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7431
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 Currently because the ldap configuration is hard coded in the script it is 
 failing to work on other setups with different ldap configuration. Please 
 move that information to test_data.py
 *Error Message*
 addLdapConfiguration failed   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=ldap
 Stacktrace
   File /usr/lib/python2.7/unittest/case.py, line 332, in run
 testMethod()
   File /root/cloudstack/test/integration/component/test_ldap.py, line 154, 
 in test_01_addLdapConfiguration
 self.assertEquals(self.ldapconfRes,1,addLdapConfiguration failed)
   File /usr/lib/python2.7/unittest/case.py, line 516, in assertEqual
 assertion_func(first, second, msg=msg)
   File /usr/lib/python2.7/unittest/case.py, line 509, in _baseAssertEqual
 raise self.failureException(msg)
 'addLdapConfiguration failed\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=ldap
   



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

[jira] [Commented] (CLOUDSTACK-7431) [Automation] Fix the script test_ldap.py - Move the Ldap configuration information to test_data.py

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit b43d9345e9716613a1b04dfaa5f50fb90caab889 in cloudstack's branch 
refs/heads/master from SrikanteswaraRao Talluri
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b43d934 ]

CLOUDSTACK-7431: moved ldap configuration details to test_data.py
Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org


 [Automation] Fix the script test_ldap.py - Move the Ldap configuration 
 information to test_data.py
 

 Key: CLOUDSTACK-7431
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7431
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 Currently because the ldap configuration is hard coded in the script it is 
 failing to work on other setups with different ldap configuration. Please 
 move that information to test_data.py
 *Error Message*
 addLdapConfiguration failed   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=ldap
 Stacktrace
   File /usr/lib/python2.7/unittest/case.py, line 332, in run
 testMethod()
   File /root/cloudstack/test/integration/component/test_ldap.py, line 154, 
 in test_01_addLdapConfiguration
 self.assertEquals(self.ldapconfRes,1,addLdapConfiguration failed)
   File /usr/lib/python2.7/unittest/case.py, line 516, in assertEqual
 assertion_func(first, second, msg=msg)
   File /usr/lib/python2.7/unittest/case.py, line 509, in _baseAssertEqual
 raise self.failureException(msg)
 'addLdapConfiguration failed\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=ldap
   



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

[jira] [Resolved] (CLOUDSTACK-7431) [Automation] Fix the script test_ldap.py - Move the Ldap configuration information to test_data.py

2014-09-04 Thread Srikanteswararao Talluri (JIRA) 

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

Srikanteswararao Talluri resolved CLOUDSTACK-7431.
--
Resolution: Fixed

 [Automation] Fix the script test_ldap.py - Move the Ldap configuration 
 information to test_data.py
 

 Key: CLOUDSTACK-7431
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7431
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 Currently because the ldap configuration is hard coded in the script it is 
 failing to work on other setups with different ldap configuration. Please 
 move that information to test_data.py
 *Error Message*
 addLdapConfiguration failed   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=ldap
 Stacktrace
   File /usr/lib/python2.7/unittest/case.py, line 332, in run
 testMethod()
   File /root/cloudstack/test/integration/component/test_ldap.py, line 154, 
 in test_01_addLdapConfiguration
 self.assertEquals(self.ldapconfRes,1,addLdapConfiguration failed)
   File /usr/lib/python2.7/unittest/case.py, line 516, in assertEqual
 assertion_func(first, second, msg=msg)
   File /usr/lib/python2.7/unittest/case.py, line 509, in _baseAssertEqual
 raise self.failureException(msg)
 'addLdapConfiguration failed\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=ldap
   



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

[jira] [Created] (CLOUDSTACK-7485) [LXC] Debian VMs fails to start in LXC host

2014-09-04 Thread shweta agarwal (JIRA) 
shweta agarwal created CLOUDSTACK-7485:
--

 Summary: [LXC] Debian VMs fails to start in LXC host
 Key: CLOUDSTACK-7485
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7485
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0


Repro steps:
Create a LXC setup
Register debian Template
Create Debian VM 


Bug:
Debian VMs fails to start

Agent log shows:
2014-09-04 17:34:01,902 DEBUG [kvm.resource.LibvirtComputingResource] 
(agentRequest-Handler-5:null) starting i-2-5-VM: domain type='lxc'
namei-2-5-VM/name
uuid6c3618c2-0189-4678-8242-f53bc1099cee/uuid
descriptionDebian GNU/Linux 6(64-bit)/description
clock offset='utc'
timer name='kvmclock' present='no' //clock
features
pae/
apic/
acpi/
/features
devices
emulator/emulator
interface type='bridge'
source bridge='brem1-533'/
mac address='02:00:22:4f:00:03'/
model type='virtio'/
bandwidth
inbound average='25600' peak='25600'/
outbound average='25600' peak='25600'/
/bandwidth
/interface
filesystem type='mount'
  source 
dir='/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/3ddee90e-6037-489c-b4ac-1df9867bf378'/
  target dir='/'/
/filesystem
serial type='pty'
target port='0'/
/serial
console type='pty'
target port='0'/
/console
/devices
memory524288/memory
devices
memballoon model='none'/
/devices
vcpu1/vcpu
os
typeexe/type
init/sbin/init/init
/os
cputune
shares500/shares
/cputune
cpu/cpuon_rebootrestart/on_reboot
on_poweroffdestroy/on_poweroff
on_crashdestroy/on_crash
/domain

2014-09-04 17  at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.domainCreateXML(Unknown Source)
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1238)
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3766)
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1332)
at com.cloud.agent.Agent.processRequest(Agent.java:503)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
at com.cloud.utils.nio.Task.run(Task.java:84)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
2014-09-04 17:34:02,207 DEBUG [kvm.storage.KVMStoragePoolManager] 
(agentRequest-Handler-5:null) Disconnecting disk 
3ddee90e-6037-489c-b4ac-1df9867bf378
2014-09-04 17:34:02,208 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-5:null) Trying to fetch storage pool 
dfa2ec3c-d133-3284-8583-0a0845aa4424 from libvirt
2014-09-04 17:34:02,231 DEBUG [cloud.agent.Agent] (agentRequest-Handler-5:null) 
Seq 1-8326029811101205191:  { Ans: , MgmtId: 233845178472723, via: 1, Ver: v1, 
Flags: 10, 
[{com.cloud.agent.api.StartAnswer:{vm:{id:5,name:i-2-5-VM,type:User,cpus:1,minSpeed:500,maxSpeed:500,minRam:536870912,maxRam:536870912,arch:x86_64,os:Debian
 GNU/Linux 6(64-bit),platfo:34:02,207 WARN  
[kvm.resource.LibvirtComputingResource] (agentRequest-Handler-5:null) 
LibvirtException
org.libvirt.LibvirtException: internal error: guest failed to start: cannot 
find init path '/sbin/init' relative to container root: No such file or 
directory

at org.libvirt.ErrorHandler.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)





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

[jira] [Assigned] (CLOUDSTACK-7433) [Automation] Fix the script test_deploy_vm_userdata_reg.py - Host credentials are hardcoded in the script

2014-09-04 Thread Srikanteswararao Talluri (JIRA) 

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

Srikanteswararao Talluri reassigned CLOUDSTACK-7433:


Assignee: Srikanteswararao Talluri

 [Automation] Fix the script test_deploy_vm_userdata_reg.py - Host 
 credentials are hardcoded in the script
 ---

 Key: CLOUDSTACK-7433
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7433
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 The host credentials are hardcoded in the script. Please take the host 
 specific information from test_data.py which is configurable.
 *Error Message*
 SSH Connection Failed   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=deploy_vm_userdata
 Stacktrace
   File /usr/lib/python2.7/unittest/case.py, line 332, in run
 testMethod()
   File 
 /root/cloudstack/test/integration/component/test_deploy_vm_userdata_reg.py, 
 line 209, in test_deployvm_userdata_post
 cmd
   File /usr/local/lib/python2.7/dist-packages/marvin/lib/utils.py, line 
 198, in get_process_status
 ssh = SshClient(hostip, port, username, password)
   File /usr/local/lib/python2.7/dist-packages/marvin/sshClient.py, line 81, 
 in __init__
 raise internalError(SSH Connection Failed)
 'SSH Connection Failed\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=deploy_vm_userdata
 



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

[jira] [Commented] (CLOUDSTACK-7433) [Automation] Fix the script test_deploy_vm_userdata_reg.py - Host credentials are hardcoded in the script

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit a8c75c197ea61728ca478657f4b9f43a51e2a60c in cloudstack's branch 
refs/heads/master from SrikanteswaraRao Talluri
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a8c75c1 ]

CLOUDSTACK-7433: removed hard coding for host credentials
Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org


 [Automation] Fix the script test_deploy_vm_userdata_reg.py - Host 
 credentials are hardcoded in the script
 ---

 Key: CLOUDSTACK-7433
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7433
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 The host credentials are hardcoded in the script. Please take the host 
 specific information from test_data.py which is configurable.
 *Error Message*
 SSH Connection Failed   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=deploy_vm_userdata
 Stacktrace
   File /usr/lib/python2.7/unittest/case.py, line 332, in run
 testMethod()
   File 
 /root/cloudstack/test/integration/component/test_deploy_vm_userdata_reg.py, 
 line 209, in test_deployvm_userdata_post
 cmd
   File /usr/local/lib/python2.7/dist-packages/marvin/lib/utils.py, line 
 198, in get_process_status
 ssh = SshClient(hostip, port, username, password)
   File /usr/local/lib/python2.7/dist-packages/marvin/sshClient.py, line 81, 
 in __init__
 raise internalError(SSH Connection Failed)
 'SSH Connection Failed\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=deploy_vm_userdata
 



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

[jira] [Created] (CLOUDSTACK-7486) [LXC] Fedora VM fails to start on LXc host

2014-09-04 Thread shweta agarwal (JIRA) 
shweta agarwal created CLOUDSTACK-7486:
--

 Summary: [LXC] Fedora VM  fails to start on LXc host
 Key: CLOUDSTACK-7486
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7486
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0


Repro Steps:
Repro steps:
Create a LXC setup
Register debian Template
Create Debian VM

Bug:
Debian VMs fails to start

Agent log shows:
2014-09-04 17:29:08,581 DEBUG [kvm.resource.LibvirtComputingResource] 
(agentRequest-Handler-2:null) starting i-2-3-VM: domain type='lxc'
namei-2-3-VM/name
uuida2dafe32-9d8c-47a8-abe5-9af100987155/uuid
descriptionFedora 9/description
clock offset='utc'
timer name='kvmclock' present='no' //clock
features
pae/
apic/
acpi/
/features
devices
emulator/emulator
interface type='bridge'
source bridge='brem1-533'/
mac address='02:00:1a:7c:00:01'/
model type='virtio'/
bandwidth
inbound average='25600' peak='25600'/
outbound average='25600' peak='25600'/
/bandwidth
/interface
filesystem type='mount'
  source 
dir='/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/36d7a92b-a78b-4f30-83bb-c65ea7768627'/
  target dir='/'/
/filesystem
serial type='pty'
target port='0'/
/serial
console type='pty'
target port='0'/
/console
/devices
memory524288/memory
devices
memballoon model='none'/
/devices
vcpu1/vcpu
os
typeexe/type
init/sbin/init/init
/os
cputune
shares500/shares
/cputune
cpu/cpuon_rebootrestart/on_reboot
on_poweroffdestroy/on_poweroff
on_crashdestroy/on_crash
/domain

2014-09-04 17:29:08,944 WARN  [kvm.resource.LibvirtComputingResource] 
(agentRequest-Handler-2:null) LibvirtExceptionon_crashdestroy/on_crash
/domain

2014-09-04 17:29:08,944 WARN  [kvm.resource.LibvirtComputingResource] 
(agentRequest-Handler-2:null) LibvirtException
org.libvirt.LibvirtException: internal error: guest failed to start: cannot 
find init path '/sbin/init' relative to container root: No such file or 
directory

at org.libvirt.ErrorHandler.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.domainCreateXML(Unknown Source)
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1238)
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3766)
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1332)
at com.cloud.agent.Agent.processRequest(Agent.java:503)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
at com.cloud.utils.nio.Task.run(Task.java:84)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
2014-09-04 17:29:08,945 DEBUG [kvm.storage.KVMStoragePoolManager] 
(agentRequest-Handler-2:null) Disconnecting disk 
36d7a92b-a78b-4f30-83bb-c65ea7768627
2014-09-04 17:29:08,945 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-2:null) Trying to fetch storage pool 
dfa2ec3c-d133-3284-8583-0a0845aa4424 from libvirt
2014-09-04 17:29:08,971 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null) 
Seq 1-8326029811101205165:  { Ans: , MgmtId: 233845178472723, via: 1, Ver: v1, 
Flags: 10, 
[{com.cloud.agent.api.StartAnswer:{vm:{id:3,name:i-2-3-VM,type:User,cpus:1,minSpeed:500,maxSpeed:500,minRam:536870912,maxRam:536870912,arch:x86_64,os:Fedora
 9,platformEmulator:Fedora

[jira] [Updated] (CLOUDSTACK-7486) [LXC] Fedora VM fails to start on LXc host

2014-09-04 Thread shweta agarwal (JIRA) 

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

shweta agarwal updated CLOUDSTACK-7486:
---
Attachment: agent.tar.gz

 [LXC] Fedora VM  fails to start on LXc host
 ---

 Key: CLOUDSTACK-7486
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7486
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0

 Attachments: agent.tar.gz


 Repro Steps:
 Repro steps:
 Create a LXC setup
 Register debian Template
 Create Debian VM
 Bug:
 Debian VMs fails to start
 Agent log shows:
 2014-09-04 17:29:08,581 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) starting i-2-3-VM: domain type='lxc'
 namei-2-3-VM/name
 uuida2dafe32-9d8c-47a8-abe5-9af100987155/uuid
 descriptionFedora 9/description
 clock offset='utc'
 timer name='kvmclock' present='no' //clock
 features
 pae/
 apic/
 acpi/
 /features
 devices
 emulator/emulator
 interface type='bridge'
 source bridge='brem1-533'/
 mac address='02:00:1a:7c:00:01'/
 model type='virtio'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 /interface
 filesystem type='mount'
   source 
 dir='/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/36d7a92b-a78b-4f30-83bb-c65ea7768627'/
   target dir='/'/
 /filesystem
 serial type='pty'
 target port='0'/
 /serial
 console type='pty'
 target port='0'/
 /console
 /devices
 memory524288/memory
 devices
 memballoon model='none'/
 /devices
 vcpu1/vcpu
 os
 typeexe/type
 init/sbin/init/init
 /os
 cputune
 shares500/shares
 /cputune
 cpu/cpuon_rebootrestart/on_reboot
 on_poweroffdestroy/on_poweroff
 on_crashdestroy/on_crash
 /domain
 2014-09-04 17:29:08,944 WARN  [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) LibvirtExceptionon_crashdestroy/on_crash
 /domain
 2014-09-04 17:29:08,944 WARN  [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-2:null) LibvirtException
 org.libvirt.LibvirtException: internal error: guest failed to start: cannot 
 find init path '/sbin/init' relative to container root: No such file or 
 directory
 at org.libvirt.ErrorHandler.processError(Unknown Source)
 at org.libvirt.Connect.processError(Unknown Source)
 at org.libvirt.Connect.processError(Unknown Source)
 at org.libvirt.Connect.domainCreateXML(Unknown Source)
 at 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1238)
 at 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3766)
 at 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1332)
 at com.cloud.agent.Agent.processRequest(Agent.java:503)
 at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
 at com.cloud.utils.nio.Task.run(Task.java:84)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 2014-09-04 17:29:08,945 DEBUG [kvm.storage.KVMStoragePoolManager] 
 (agentRequest-Handler-2:null) Disconnecting disk 
 36d7a92b-a78b-4f30-83bb-c65ea7768627
 2014-09-04 17:29:08,945 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-2:null) Trying to fetch storage pool 
 dfa2ec3c-d133-3284-8583-0a0845aa4424 from libvirt
 2014-09-04 17:29:08,971 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-2:null) Seq 1-8326029811101205165:  { Ans: , MgmtId: 
 233845178472723, via: 1, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.StartAnswer:{vm:{id:3,name:i-2-3-VM,type:User,cpus:1,minSpeed:500,maxSpeed:500,minRam:536870912,maxRam:536870912,arch:x86_64,os:Fedora
  9,platformEmulator:Fedora

[jira] [Updated] (CLOUDSTACK-7485) [LXC] Debian VMs fails to start in LXC host

2014-09-04 Thread shweta agarwal (JIRA) 

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

shweta agarwal updated CLOUDSTACK-7485:
---
Attachment: agent.tar.gz

 [LXC] Debian VMs fails to start in LXC host
 ---

 Key: CLOUDSTACK-7485
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7485
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0

 Attachments: agent.tar.gz


 Repro steps:
 Create a LXC setup
 Register debian Template
 Create Debian VM 
 Bug:
 Debian VMs fails to start
 Agent log shows:
 2014-09-04 17:34:01,902 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-5:null) starting i-2-5-VM: domain type='lxc'
 namei-2-5-VM/name
 uuid6c3618c2-0189-4678-8242-f53bc1099cee/uuid
 descriptionDebian GNU/Linux 6(64-bit)/description
 clock offset='utc'
 timer name='kvmclock' present='no' //clock
 features
 pae/
 apic/
 acpi/
 /features
 devices
 emulator/emulator
 interface type='bridge'
 source bridge='brem1-533'/
 mac address='02:00:22:4f:00:03'/
 model type='virtio'/
 bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
 /bandwidth
 /interface
 filesystem type='mount'
   source 
 dir='/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/3ddee90e-6037-489c-b4ac-1df9867bf378'/
   target dir='/'/
 /filesystem
 serial type='pty'
 target port='0'/
 /serial
 console type='pty'
 target port='0'/
 /console
 /devices
 memory524288/memory
 devices
 memballoon model='none'/
 /devices
 vcpu1/vcpu
 os
 typeexe/type
 init/sbin/init/init
 /os
 cputune
 shares500/shares
 /cputune
 cpu/cpuon_rebootrestart/on_reboot
 on_poweroffdestroy/on_poweroff
 on_crashdestroy/on_crash
 /domain
 2014-09-04 17  at org.libvirt.Connect.processError(Unknown Source)
 at org.libvirt.Connect.domainCreateXML(Unknown Source)
 at 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1238)
 at 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3766)
 at 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1332)
 at com.cloud.agent.Agent.processRequest(Agent.java:503)
 at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
 at com.cloud.utils.nio.Task.run(Task.java:84)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 2014-09-04 17:34:02,207 DEBUG [kvm.storage.KVMStoragePoolManager] 
 (agentRequest-Handler-5:null) Disconnecting disk 
 3ddee90e-6037-489c-b4ac-1df9867bf378
 2014-09-04 17:34:02,208 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-5:null) Trying to fetch storage pool 
 dfa2ec3c-d133-3284-8583-0a0845aa4424 from libvirt
 2014-09-04 17:34:02,231 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-5:null) Seq 1-8326029811101205191:  { Ans: , MgmtId: 
 233845178472723, via: 1, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.StartAnswer:{vm:{id:5,name:i-2-5-VM,type:User,cpus:1,minSpeed:500,maxSpeed:500,minRam:536870912,maxRam:536870912,arch:x86_64,os:Debian
  GNU/Linux 6(64-bit),platfo:34:02,207 WARN  
 [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-5:null) 
 LibvirtException
 org.libvirt.LibvirtException: internal error: guest failed to start: cannot 
 find init path '/sbin/init' relative to container root: No such file or 
 directory
 at org.libvirt.ErrorHandler.processError(Unknown Source)
 at org.libvirt.Connect.processError(Unknown Source)
 at org.libvirt.Connect.processError(Unknown Source)



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

[jira] [Created] (CLOUDSTACK-7487) [UI] Public, Featured, routing option are not shown while registering templates

2014-09-04 Thread shweta agarwal (JIRA) 
shweta agarwal created CLOUDSTACK-7487:
--

 Summary: [UI] Public, Featured, routing  option are not shown 
while registering templates
 Key: CLOUDSTACK-7487
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7487
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.5.0
Reporter: shweta agarwal
 Fix For: 4.5.0


Repro steps:
Open RegisterTemplate dialog box
Notice Public, Featured and routing  option check boxes  are not shown while 
registering templates

Attaching screenshot



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

[jira] [Resolved] (CLOUDSTACK-7228) [Automation] Unable to shrink data disk attached to a VM on XenServer

2014-09-04 Thread Srikanteswararao Talluri (JIRA) 

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

Srikanteswararao Talluri resolved CLOUDSTACK-7228.
--
Resolution: Fixed

This should get fixed with John's patch. Marking it fixed. Please reopen if 
this reappears. 

 [Automation] Unable to shrink data disk attached to a VM on XenServer
 -

 Key: CLOUDSTACK-7228
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7228
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test, Volumes
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0

 Attachments: management-server.zip


 ==
 Automation Code:
 ==
 def test_08_resize_volume(self):
 Test resize a volume
 #Verify the size is the new size is what we wanted it to be.
 self.debug(
 Attaching volume (ID: %s) to VM (ID: %s) % (
 self.volume.id,
 self.virtual_machine.id
 ))
 self.virtual_machine.attach_volume(self.apiClient, self.volume)
 self.attached = True
 hosts = Host.list(self.apiClient, id=self.virtual_machine.hostid)
 self.assertTrue(isinstance(hosts, list))
 self.assertTrue(len(hosts)  0)
 self.debug(Found %s host % hosts[0].hypervisor)
 if hosts[0].hypervisor == XenServer:
 self.virtual_machine.stop(self.apiClient)
 elif hosts[0].hypervisor.lower() == vmware:
 self.skipTest(Resize Volume is unsupported on VmWare)
 #resize the data disk
 self.debug(Resize Volume ID: %s % self.volume.id)
 self.services[disk_offering][disksize] = 20
 disk_offering_20_GB = DiskOffering.create(
 self.apiclient,
 self.services[disk_offering]
 )
 self.cleanup.append(disk_offering_20_GB)
 cmd= resizeVolume.resizeVolumeCmd()
 cmd.id = self.volume.id
 cmd.diskofferingid = disk_offering_20_GB.id
 self.apiClient.resizeVolume(cmd)
 ===
 Error Thrown in Automation Logs:
 ===
 =
 ERROR: Test resize a volume
 
 Traceback (most recent call last):
   File /home/chandan/test_volumes.py, line 693, in test_08_resize_volume
 self.apiClient.resizeVolume(cmd)
   File 
 /usr/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
  line 1672, in resizeVolume
 response = self.connection.marvinRequest(command, response_type=response, 
 method=method)
   File /usr/lib/python2.7/site-packages/marvin/cloudstackConnection.py, 
 line 379, in marvinRequest
 raise e
 Exception: Job failed: {jobprocstatus : 0, created : 
 u'2014-08-07T16:45:25-0700', cmd : 
 u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin', 
 userid : u'89a9018a-12a8-11e4-b75e-06098c000757', jobstatus : 2, jobid : 
 u'7d5c9749-67d6-4fab-a0bf-f5bc8722b276', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : u'Job failed due to 
 exception failed to resize volume:SR_BACKEND_FAILURE_79VDI Invalid size 
 [opterr=shrinking not allowed]'}, accountid : 
 u'89a8f4e2-12a8-11e4-b75e-06098c000757'}
   begin captured stdout  -
 === TestName: test_08_resize_volume | Status : EXCEPTION ===
 ==
 Error in Management Server Log:
 ==
 2014-08-07 14:15:39,459 DEBUG [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-23:ctx-62ca6450 job-1314/job-1315 ctx-0761b68e) Execute VM 
 work job: 
 com.cloud.storage.VmWorkResizeVolume{volumeId:172,currentSize:21474836480,newSize:10737418240,newServiceOfferingId:43,shrinkOk:true,userId:2,accountId:2,vmId:162,handlerName:VolumeApiServiceImpl}
 2014-08-07 14:15:39,487 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-23:ctx-62ca6450 job-1314/job-1315 ctx-0761b68e) Seq 
 1-1425952232016183856: Sending  { Cmd , MgmtId: 6638073284439, via: 
 1(Rack3Host6.lab.vmops.com), Ver: v1, Flags: 100011,

[jira] [Updated] (CLOUDSTACK-7487) [UI] Public, Featured, routing option are not shown while registering templates

2014-09-04 Thread shweta agarwal (JIRA) 

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

shweta agarwal updated CLOUDSTACK-7487:
---
Attachment: template.png

 [UI] Public, Featured, routing  option are not shown while registering 
 templates
 

 Key: CLOUDSTACK-7487
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7487
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.5.0
Reporter: shweta agarwal
 Fix For: 4.5.0

 Attachments: template.png


 Repro steps:
 Open RegisterTemplate dialog box
 Notice Public, Featured and routing  option check boxes  are not shown while 
 registering templates
 Attaching screenshot



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

[jira] [Commented] (CLOUDSTACK-7442) [Automation] Fix the script test_project_resources.py - No permissions updated, please verify the account names

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

CLOUDSTACK-7442: Fixed template permission issue in test_project_resources.py

Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org


 [Automation] Fix the script test_project_resources.py - No permissions 
 updated, please verify the account names
 -

 Key: CLOUDSTACK-7442
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7442
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 The following script failed during regression run:
 integration.component.test_project_resources.TestTemplates.test_05_use_private_template_in_project
  
 *Error Message*
 Exception occured: Execute cmd: updatetemplatepermissions failed, due to: 
 errorCode: 431, errorText:Unable to grant a launch permission to account 
 PrjAcct-Project-TQDWSH-99 in domain id=56ab18f0-2b4d-11e4-89bd-1e5d0e053e75, 
 account not found.  No permissions updated, please verify the account names 
 and retry.   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=project_resources
 Stacktrace
   File /usr/lib/python2.7/unittest/case.py, line 332, in run
 testMethod()
   File 
 /root/cloudstack/test/integration/component/test_project_resources.py, line 
 768, in test_05_use_private_template_in_project
 self.fail(Exception occured: %s % e)
   File /usr/lib/python2.7/unittest/case.py, line 413, in fail
 raise self.failureException(msg)
 'Exception occured: Execute cmd: updatetemplatepermissions failed, due to: 
 errorCode: 431, errorText:Unable to grant a launch permission to account 
 PrjAcct-Project-TQDWSH-99 in domain id=56ab18f0-2b4d-11e4-89bd-1e5d0e053e75, 
 account not found.  No permissions updated, please verify the account names 
 and retry.\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=project_resources
  



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

[jira] [Resolved] (CLOUDSTACK-7442) [Automation] Fix the script test_project_resources.py - No permissions updated, please verify the account names

2014-09-04 Thread Srikanteswararao Talluri (JIRA) 

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

Srikanteswararao Talluri resolved CLOUDSTACK-7442.
--
Resolution: Fixed

 [Automation] Fix the script test_project_resources.py - No permissions 
 updated, please verify the account names
 -

 Key: CLOUDSTACK-7442
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7442
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 The following script failed during regression run:
 integration.component.test_project_resources.TestTemplates.test_05_use_private_template_in_project
  
 *Error Message*
 Exception occured: Execute cmd: updatetemplatepermissions failed, due to: 
 errorCode: 431, errorText:Unable to grant a launch permission to account 
 PrjAcct-Project-TQDWSH-99 in domain id=56ab18f0-2b4d-11e4-89bd-1e5d0e053e75, 
 account not found.  No permissions updated, please verify the account names 
 and retry.   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=project_resources
 Stacktrace
   File /usr/lib/python2.7/unittest/case.py, line 332, in run
 testMethod()
   File 
 /root/cloudstack/test/integration/component/test_project_resources.py, line 
 768, in test_05_use_private_template_in_project
 self.fail(Exception occured: %s % e)
   File /usr/lib/python2.7/unittest/case.py, line 413, in fail
 raise self.failureException(msg)
 'Exception occured: Execute cmd: updatetemplatepermissions failed, due to: 
 errorCode: 431, errorText:Unable to grant a launch permission to account 
 PrjAcct-Project-TQDWSH-99 in domain id=56ab18f0-2b4d-11e4-89bd-1e5d0e053e75, 
 account not found.  No permissions updated, please verify the account names 
 and retry.\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=project_resources
  



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

[jira] [Resolved] (CLOUDSTACK-7426) [Automation] Failed to update template permissions in test_05_use_private_template_in_project

2014-09-04 Thread Srikanteswararao Talluri (JIRA) 

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

Srikanteswararao Talluri resolved CLOUDSTACK-7426.
--
Resolution: Fixed

 [Automation] Failed to update template permissions in 
 test_05_use_private_template_in_project
 -

 Key: CLOUDSTACK-7426
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7426
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 Error while executing the following test
 *integration.component.test_project_resources.TestTemplates.test_05_use_private_template_in_project
  (from nosetests)*
 *Error Message*
 Exception occured: Execute cmd: updatetemplatepermissions failed, due to: 
 errorCode: 431, errorText:Unable to grant a launch permission to account 
 PrjAcct-Project-TQDWSH-99 in domain id=56ab18f0-2b4d-11e4-89bd-1e5d0e053e75, 
 account not found.  No permissions updated, please verify the account names 
 and retry.   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=project_resources
 Stacktrace
   File /usr/lib/python2.7/unittest/case.py, line 332, in run
 testMethod()
   File 
 /root/cloudstack/test/integration/component/test_project_resources.py, line 
 768, in test_05_use_private_template_in_project
 self.fail(Exception occured: %s % e)
   File /usr/lib/python2.7/unittest/case.py, line 413, in fail
 raise self.failureException(msg)
 'Exception occured: Execute cmd: updatetemplatepermissions failed, due to: 
 errorCode: 431, errorText:Unable to grant a launch permission to account 
 PrjAcct-Project-TQDWSH-99 in domain id=56ab18f0-2b4d-11e4-89bd-1e5d0e053e75, 
 account not found.  No permissions updated, please verify the account names 
 and retry.\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=project_resources
  



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

[jira] [Commented] (CLOUDSTACK-7143) Refactor systemvm build scripts to be easier to test

2014-09-04 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-7143:


GitHub user lsimons opened a pull request:

https://github.com/apache/cloudstack/pull/16

CLOUDSTACK-7143: Refactoring of the systemvm build process

E-mail thread:
  
http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201407.mbox/%3C7A6CF878-7A28-4D4A-BCD2-0C264F8C90B7%40schubergphilis.com%3E

This started out as wanting the systemvm build to take
systemvm/patches/debian/{debian,vpn} from the local machine/branch,
rather than downloading from the apache git master [1]. In working out
how on earth to get veewee to do that cleanly (hint: you can’t, hence
resorting to shar usage) I got quite frustrated with the image rebuild
times.

It so happens that veewee has a --skip-to-postinstall instruction which
is _quite_ useful while debugging these scripts. To get that working
requires the post install steps to be retryable/convergent. Of course,
our existing scripts weren’t set up for that. So I had to add a bunch
of tests whether changes had applied already. Which implied a pretty
significant refactor.

Summarizing this kind of thing is always hard...it’s many little
things...the interesting stuff is at the end/bottom, in particular
the two main improvements

  
https://github.com/schubergphilis/cloudstack/commit/142d087f6a97f6ac70a858a35d2fe8b638c58cbb
When working on the systemvm in isolation, or using vagrant or
similar tools, it can be useful to inject a custom SSH key before
merging a management server systemvm.iso into it. This option
allows that. It should _not_ have effect on management-server-
managed vms which always get their SSH keys injected.

  
https://github.com/schubergphilis/cloudstack/commit/e2240eaed18000d4d94dbf6a6e40612db1aeda34
The current build downloads its script from master by fetching a
cloudstack tarball. Besides being an unneeded load on the apache
git server, this is a problem when working on a branch and
wanting to inject a different set of scripts. It also makes it
pretty likely that the injected copy of the script will not match
what a production release wants, so there is very little chance of
not needing to overwrite the scripts.

Ideally we would just rsync over some files. However, veewee does
not provide an option to do that. In order to keep a 'cleanly
veewee-only' build possible, and work with any recent veewee
version, in this change we restor to using shar
(http://en.wikipedia.org/wiki/Shar) to produce an archive which
can execute as a script, which we feed to veewee to execute.

In order to avoid having to re-do this cleanup twice, I also ended up
merging the systemvm and systemvm64 template definitions, factoring out
their small differences by inspecting the os architecture.

  
https://github.com/schubergphilis/cloudstack/commit/f570b3921cd52672f841fc5f99cdd96f9737d629
  
https://github.com/schubergphilis/cloudstack/commit/50e91217f90fc952182dccac02a5af06ac33fb45

Everything else…well it pretty much falls into two categories:
  * general code cleanup without functional changes
  * general code defensiveness to survive various jenkins build
scenarios

All in all it should help with ongoing maintenance, I think.

Most of these commits are now a while old but I wanted to wait with
sending this upstream until we had sufficiently tested the systemvms
built with this changed approach locally.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/schubergphilis/cloudstack 
feature/systemvm-refactor-for-upstream

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/16.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #16


commit 49cbb4e20b70a19286c626ac8d9111be8752bc3f
Author: Leo Simons lsim...@schubergphilis.com
Date:   2014-07-21T07:54:13Z

CLOUDSTACK-7143: upgrade systemvm to latest debian stable, 7.6.0.

commit 35b1875226201d5923dea57db64bbd789d9ad908
Author: Leo Simons lsim...@schubergphilis.com
Date:   2014-07-21T07:55:37Z

CLOUDSTACK-7143: split base.sh into its two functions.

commit fb258b506964ca339ef85aa92a6217dc12259811
Author: Leo Simons lsim...@schubergphilis.com
Date:   2014-07-21T07:57:49Z

CLOUDSTACK-7143: move network tuning from cleanup.sh to its own script.

commit 50e2c0177b0df04aa80d19264d52c8d55dc02eb3
Author: Leo Simons

[jira] [Created] (CLOUDSTACK-7488) Releasing an IP address that has a LBR with a SSL certificate does not remove the LBR-SSL mapping (which breaks SSL Cert listing)

2014-09-04 Thread Patrick D. (JIRA) 
Patrick D. created CLOUDSTACK-7488:
--

 Summary: Releasing an IP address that has a LBR with a SSL 
certificate does not remove the LBR-SSL mapping (which breaks SSL Cert listing)
 Key: CLOUDSTACK-7488
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7488
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.4.0
Reporter: Patrick D.


In relation to CLOUDSTACK-7418



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

[jira] [Commented] (CLOUDSTACK-7143) Refactor systemvm build scripts to be easier to test

2014-09-04 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-7143:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/16#issuecomment-54487736
  
Hi Leo, thanks for the PR.

I see you've refactored the 32 and 64 bit building scripts to one which is 
great!
I'll be able to test it next week and help you get it fixed if needed and 
merged. Meanwhile you may ask Hugo to set a test build job for testing the 
appliances. And some basic tests using those built systemvm templates both 32 
and 64 bits.


 Refactor systemvm build scripts to be easier to test
 

 Key: CLOUDSTACK-7143
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7143
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: SystemVM
Reporter: Leo Simons
 Fix For: Future


 The veewee-wrapping build code could do with some love.
 E-mail thread: 
 http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201407.mbox/%3C7A6CF878-7A28-4D4A-BCD2-0C264F8C90B7%40schubergphilis.com%3E



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

[jira] [Commented] (CLOUDSTACK-7143) Refactor systemvm build scripts to be easier to test

2014-09-04 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-7143:


Github user lsimons commented on the pull request:

https://github.com/apache/cloudstack/pull/16#issuecomment-54490782
  
Hey Rohit, thanks for reviewing!

We actually have a new vagrant-based component test setup for the systemvm 
to contribute, too; I'm working on extracting that now from the schubergphilis 
feature/systemvm-persistent-config branch. Our internal jenkins setup is 
already running those tests, as well as wider-scale marvin-driven integration 
tests that use these new-style systemvms. That's why I think this is ready for 
upstream: I'm pretty confident this stuff all still works properly.tough of 
course that _really_ _really_ needs careful verification outside of our 
assumptions/environment.

I'll try and work with Hugo to port those jenkins builds to 
buildacloud.org...hope he has time for it :)



 Refactor systemvm build scripts to be easier to test
 

 Key: CLOUDSTACK-7143
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7143
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: SystemVM
Reporter: Leo Simons
 Fix For: Future


 The veewee-wrapping build code could do with some love.
 E-mail thread: 
 http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201407.mbox/%3C7A6CF878-7A28-4D4A-BCD2-0C264F8C90B7%40schubergphilis.com%3E



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

[jira] [Commented] (CLOUDSTACK-7473) [LXC]putting host into maintenance is failing

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

CLOUDSTACK-7473: Vm migration is not supported for LXC. When host is put in 
maintenance mode, stop the Vms instead of migrating


 [LXC]putting host into maintenance is failing 
 --

 Key: CLOUDSTACK-7473
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7473
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Blocker
 Attachments: agent.log.tar.gz, ms.tar.gz


 Repro stesp:
 1. create a zone with a LXC cluster having 2 host
 2. create few LXC vms
 3. Put one host into maintenance which has some VM  running
 Bug:
 Putting host into maintenance will never pass. host will remain in preparing 
 for maintenance stage and then goes to disconnect state.
 Agent log shows :
 2014-09-02 19:08:12,663 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-1:null) Failed to execute while migrating domain: 
 org.libvirt.LibvirtException: this function is not supported by the 
 connection driver: virDomainMigrate2
 2014-09-02 19:08:12,665 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-1:null) Seq 1-3693233169420517550:  { Ans: , MgmtId: 
 233845178472723, via: 1, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.MigrateAnswer:{result:false,details:org.libvirt.LibvirtException:
  this function is not supported by the connection driver: 
 virDomainMigrate2,wait:0}}] }
 2014-09-02 19:08:13,004 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-4:null) Request:Seq 1-3693233169420517551:  { Cmd , 
 MgmtId: 233845178472723, via: 1, Ver: v1, Flags: 100011, 
 [{com.cloud.agent.api.MigrateCommand:{vmName:i-2-7-VM,destIp:10.147.28.49,hostGuid:2b2a1b9f-7582-378f-b54f-1dbb8f69e239-LibvirtComputingResource,isWindows:false,vmTO:{id:7,name:i-2-7-VM,type:User,cpus:1,minSpeed:128,maxSpeed:128,minRam:134217728,maxRam:134217728,arch:x86_64,os:Red
  Hat Enterprise Linux 
 7.0,platformEmulator:Other,bootArgs:,enableHA:true,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:QY0cKnTfogzaS49R283f1g==,params:{Message.ReservedCapacityFreed.Flag:false},uuid:caf07a92-9f6c-49df-a7e4-27289e715448,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:981fe152-6ee5--ae41-474736c881cf,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:dfa2ec3c-d133-3284-8583-0a0845aa4424,id:1,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/shweta/goleta.lxc.primary,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=PrimarySTOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424}},name:ROOT-7,size:647321600,path:981fe152-6ee5--ae41-474736c881cf,volumeId:7,vmName:i-2-7-VM,accountId:2,format:DIR,provisioningType:THIN,id:7,deviceId:0,hypervisorType:LXC}},diskSeq:0,path:981fe152-6ee5--ae41-474736c881cf,type:ROOT,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:647321600}},{data:{org.apache.cloudstack.storage.to.TemplateObjectTO:{id:0,format:ISO,accountId:0,hvm:false}},diskSeq:3,type:ISO}],nics:[{deviceId:0,networkRateMbps:200,defaultNic:true,pxeDisable:false,nicUuid:95826449-4163-46b8-91b7-8bf94f19ab8e,uuid:d4db3da8-4e6c-4e29-b6bb-a6613d55fa2f,ip:10.147.30.166,netmask:255.255.255.0,gateway:10.147.30.1,mac:06:54:96:00:00:07,dns1:10.140.50.6,broadcastType:Vlan,type:Guest,broadcastUri:vlan://30,isolationUri:vlan://30,isSecurityGroupEnabled:true}]},executeInSequence:false,wait:0}}]
  }
 2014-09-02 19:08:13,005 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-4:null) Processing command: 
 com.cloud.agent.api.MigrateCommand
 2014-09-02 19:08:13,006 DEBUG [kvm.resource.LibvirtConnection] 
 (agentRequest-Handler-4:null) can't find connection: KVM, for vm: i-2-7-VM, 
 continue
 2014-09-02 19:08:13,018 INFO  [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-4:null) Live migration of instance i-2-7-VM initiated
 2014-09-02 19:08:13,103 INFO  [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-5:null) Waiting for migration of s-1-VM to complete, 
 waited 1000ms
 2014-09-02 19:08:13,118 INFO  [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-4:null) Migration thread for i-2-7-VM is done
 2014-09-02 19:08:13,119 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-4:null) Failed to

[jira] [Resolved] (CLOUDSTACK-7473) [LXC]putting host into maintenance is failing

2014-09-04 Thread Kishan Kavala (JIRA) 

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

Kishan Kavala resolved CLOUDSTACK-7473.
---
Resolution: Fixed

 [LXC]putting host into maintenance is failing 
 --

 Key: CLOUDSTACK-7473
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7473
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Blocker
 Attachments: agent.log.tar.gz, ms.tar.gz


 Repro stesp:
 1. create a zone with a LXC cluster having 2 host
 2. create few LXC vms
 3. Put one host into maintenance which has some VM  running
 Bug:
 Putting host into maintenance will never pass. host will remain in preparing 
 for maintenance stage and then goes to disconnect state.
 Agent log shows :
 2014-09-02 19:08:12,663 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-1:null) Failed to execute while migrating domain: 
 org.libvirt.LibvirtException: this function is not supported by the 
 connection driver: virDomainMigrate2
 2014-09-02 19:08:12,665 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-1:null) Seq 1-3693233169420517550:  { Ans: , MgmtId: 
 233845178472723, via: 1, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.MigrateAnswer:{result:false,details:org.libvirt.LibvirtException:
  this function is not supported by the connection driver: 
 virDomainMigrate2,wait:0}}] }
 2014-09-02 19:08:13,004 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-4:null) Request:Seq 1-3693233169420517551:  { Cmd , 
 MgmtId: 233845178472723, via: 1, Ver: v1, Flags: 100011, 
 [{com.cloud.agent.api.MigrateCommand:{vmName:i-2-7-VM,destIp:10.147.28.49,hostGuid:2b2a1b9f-7582-378f-b54f-1dbb8f69e239-LibvirtComputingResource,isWindows:false,vmTO:{id:7,name:i-2-7-VM,type:User,cpus:1,minSpeed:128,maxSpeed:128,minRam:134217728,maxRam:134217728,arch:x86_64,os:Red
  Hat Enterprise Linux 
 7.0,platformEmulator:Other,bootArgs:,enableHA:true,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:QY0cKnTfogzaS49R283f1g==,params:{Message.ReservedCapacityFreed.Flag:false},uuid:caf07a92-9f6c-49df-a7e4-27289e715448,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:981fe152-6ee5--ae41-474736c881cf,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:dfa2ec3c-d133-3284-8583-0a0845aa4424,id:1,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/shweta/goleta.lxc.primary,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=PrimarySTOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424}},name:ROOT-7,size:647321600,path:981fe152-6ee5--ae41-474736c881cf,volumeId:7,vmName:i-2-7-VM,accountId:2,format:DIR,provisioningType:THIN,id:7,deviceId:0,hypervisorType:LXC}},diskSeq:0,path:981fe152-6ee5--ae41-474736c881cf,type:ROOT,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:647321600}},{data:{org.apache.cloudstack.storage.to.TemplateObjectTO:{id:0,format:ISO,accountId:0,hvm:false}},diskSeq:3,type:ISO}],nics:[{deviceId:0,networkRateMbps:200,defaultNic:true,pxeDisable:false,nicUuid:95826449-4163-46b8-91b7-8bf94f19ab8e,uuid:d4db3da8-4e6c-4e29-b6bb-a6613d55fa2f,ip:10.147.30.166,netmask:255.255.255.0,gateway:10.147.30.1,mac:06:54:96:00:00:07,dns1:10.140.50.6,broadcastType:Vlan,type:Guest,broadcastUri:vlan://30,isolationUri:vlan://30,isSecurityGroupEnabled:true}]},executeInSequence:false,wait:0}}]
  }
 2014-09-02 19:08:13,005 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-4:null) Processing command: 
 com.cloud.agent.api.MigrateCommand
 2014-09-02 19:08:13,006 DEBUG [kvm.resource.LibvirtConnection] 
 (agentRequest-Handler-4:null) can't find connection: KVM, for vm: i-2-7-VM, 
 continue
 2014-09-02 19:08:13,018 INFO  [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-4:null) Live migration of instance i-2-7-VM initiated
 2014-09-02 19:08:13,103 INFO  [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-5:null) Waiting for migration of s-1-VM to complete, 
 waited 1000ms
 2014-09-02 19:08:13,118 INFO  [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-4:null) Migration thread for i-2-7-VM is done
 2014-09-02 19:08:13,119 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-4:null) Failed to execute while migrating domain: 
 org.libvirt.LibvirtException: this function is not supported by the 
 connection driver: virDomainMigrate2
 2014-09-02 19:08:13,124 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-4:null) Seq 1-3693233169420517551:  { Ans: , MgmtId: 
 233845178472723, via: 1, Ver: v1, Flags: 10,

[jira] [Updated] (CLOUDSTACK-7291) LXC: Mgmt server/agent keeps killing systemvms

2014-09-04 Thread Sudha Ponnaganti (JIRA) 

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

Sudha Ponnaganti updated CLOUDSTACK-7291:
-
Affects Version/s: 4.5.0

 LXC: Mgmt server/agent keeps killing systemvms
 --

 Key: CLOUDSTACK-7291
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7291
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.3.0, 4.5.0, 4.3.1
Reporter: Rohit Yadav
Priority: Blocker
 Fix For: 4.5.0, 4.3.1


 Followed installation and setup docs of 4.3, was unable to get LXC to work on 
 Ubuntu 14.04/trusty. The systemvms kept coming up and result from 
 ssvm_check.sh was good and it was able to reach mgmt server /host, even then 
 mgmt server complained that it was unable to contact agent on the systemvm 
 (ping), while the agent would gracefully shutdown the systemvm (by killing 
 them).
 Relevant log:
 2014-08-07 19:52:26,294 INFO  [c.c.u.e.CSExceptionErrorCode] 
 (secstorage-1:ctx-fc57ef43) Could not find exception: 
 com.cloud.exception.OperationTimedoutException in error code list for 
 exceptions
 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host 
 Host[-1-Routing]
 2014-08-07 19:52:26,295 DEBUG [c.c.a.m.AgentAttache] 
 (consoleproxy-1:ctx-e123fa9c) Seq 1-51249205: Cancelling.
 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host 
 Host[-1-Routing]
 2014-08-07 19:52:26,303 DEBUG [c.c.h.Status] (AgentTaskPool-13:ctx-0b35e679) 
 Transition:[Resource state = Enabled, Agent event = ShutdownRequested, Host 
 id = 1, name = bluebox1.bhaisaab.org]
 2014-08-07 19:52:26,311 DEBUG [c.c.h.HighAvailabilityManagerImpl] 
 (secstorage-1:ctx-fc57ef43) Scheduled 
 HAWork[12-CheckStop-2-Starting-Scheduled]
 2014-08-07 19:52:26,314 WARN  [c.c.s.s.SecondaryStorageManagerImpl] 
 (secstorage-1:ctx-fc57ef43) Exception while trying to start secondary storage 
 vm
 com.cloud.exception.AgentUnavailableException: Resource [Host:1] is 
 unreachable: Host 1: Unable to start s-2-VM
 ---at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1051)
 ---at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761)
 ---at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745)
 ---at 
 com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261)
 ---at 
 com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:694)
 ---at 
 com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1278)
 ---at 
 com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123)
 ---at 
 com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50)
 ---at 
 com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111) 
 ...
 ...
 ...
 Caused by: com.cloud.exception.OperationTimedoutException: Commands 51249206 
 to Host 1 timed out after 3600
 ---at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:439)   
  
 ---at 
 com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:394)
 ---at 
 com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:920)
 ---at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:989)
 ---... 24 more   
  



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

[jira] [Updated] (CLOUDSTACK-7291) LXC: Mgmt server/agent keeps killing systemvms

2014-09-04 Thread Sudha Ponnaganti (JIRA) 

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

Sudha Ponnaganti updated CLOUDSTACK-7291:
-
Fix Version/s: 4.5.0

 LXC: Mgmt server/agent keeps killing systemvms
 --

 Key: CLOUDSTACK-7291
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7291
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.3.0, 4.5.0, 4.3.1
Reporter: Rohit Yadav
Priority: Blocker
 Fix For: 4.5.0, 4.3.1


 Followed installation and setup docs of 4.3, was unable to get LXC to work on 
 Ubuntu 14.04/trusty. The systemvms kept coming up and result from 
 ssvm_check.sh was good and it was able to reach mgmt server /host, even then 
 mgmt server complained that it was unable to contact agent on the systemvm 
 (ping), while the agent would gracefully shutdown the systemvm (by killing 
 them).
 Relevant log:
 2014-08-07 19:52:26,294 INFO  [c.c.u.e.CSExceptionErrorCode] 
 (secstorage-1:ctx-fc57ef43) Could not find exception: 
 com.cloud.exception.OperationTimedoutException in error code list for 
 exceptions
 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host 
 Host[-1-Routing]
 2014-08-07 19:52:26,295 DEBUG [c.c.a.m.AgentAttache] 
 (consoleproxy-1:ctx-e123fa9c) Seq 1-51249205: Cancelling.
 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host 
 Host[-1-Routing]
 2014-08-07 19:52:26,303 DEBUG [c.c.h.Status] (AgentTaskPool-13:ctx-0b35e679) 
 Transition:[Resource state = Enabled, Agent event = ShutdownRequested, Host 
 id = 1, name = bluebox1.bhaisaab.org]
 2014-08-07 19:52:26,311 DEBUG [c.c.h.HighAvailabilityManagerImpl] 
 (secstorage-1:ctx-fc57ef43) Scheduled 
 HAWork[12-CheckStop-2-Starting-Scheduled]
 2014-08-07 19:52:26,314 WARN  [c.c.s.s.SecondaryStorageManagerImpl] 
 (secstorage-1:ctx-fc57ef43) Exception while trying to start secondary storage 
 vm
 com.cloud.exception.AgentUnavailableException: Resource [Host:1] is 
 unreachable: Host 1: Unable to start s-2-VM
 ---at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1051)
 ---at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761)
 ---at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745)
 ---at 
 com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261)
 ---at 
 com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:694)
 ---at 
 com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1278)
 ---at 
 com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123)
 ---at 
 com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50)
 ---at 
 com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111) 
 ...
 ...
 ...
 Caused by: com.cloud.exception.OperationTimedoutException: Commands 51249206 
 to Host 1 timed out after 3600
 ---at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:439)   
  
 ---at 
 com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:394)
 ---at 
 com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:920)
 ---at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:989)
 ---... 24 more   
  



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

[jira] [Commented] (CLOUDSTACK-7488) Releasing an IP address that has a LBR with a SSL certificate does not remove the LBR-SSL mapping (which breaks SSL Cert listing)

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit 6c501dba45468d216f0d3d41adaa8e05cc083321 in cloudstack's branch 
refs/heads/hotfix/4.4-7418 from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6c501db ]

CLOUDSTACK-7418 and CLOUDSTACK-7488 - Fixed LB removal if cert is associated


 Releasing an IP address that has a LBR with a SSL certificate does not remove 
 the LBR-SSL mapping (which breaks SSL Cert listing)
 -

 Key: CLOUDSTACK-7488
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7488
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Patrick D.

 In relation to CLOUDSTACK-7418



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

[jira] [Commented] (CLOUDSTACK-7418) Deleting a load balancer rule that has an SSL cert assigned to it does not delete the mapping in the load_balancer_cert_map table

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit 6c501dba45468d216f0d3d41adaa8e05cc083321 in cloudstack's branch 
refs/heads/hotfix/4.4-7418 from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6c501db ]

CLOUDSTACK-7418 and CLOUDSTACK-7488 - Fixed LB removal if cert is associated


 Deleting a load balancer rule that has an SSL cert assigned to it does not 
 delete the mapping in the load_balancer_cert_map table
 -

 Key: CLOUDSTACK-7418
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7418
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Patrick D.

 This causes a Null Pointer Exception when listing the SSL certificates 
 because it tries to get the ID of a lbr that does not exist anymore.



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

[jira] [Commented] (CLOUDSTACK-7488) Releasing an IP address that has a LBR with a SSL certificate does not remove the LBR-SSL mapping (which breaks SSL Cert listing)

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit 18653f6cd6a899c61a51057a717d0027717fd0a5 in cloudstack's branch 
refs/heads/CLOUDSTACK-7418 from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=18653f6 ]

CLOUDSTACK-7418 and CLOUDSTACK-7488 - Fixed LB removal if cert is applied


 Releasing an IP address that has a LBR with a SSL certificate does not remove 
 the LBR-SSL mapping (which breaks SSL Cert listing)
 -

 Key: CLOUDSTACK-7488
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7488
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Patrick D.

 In relation to CLOUDSTACK-7418



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

[jira] [Commented] (CLOUDSTACK-7418) Deleting a load balancer rule that has an SSL cert assigned to it does not delete the mapping in the load_balancer_cert_map table

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit 18653f6cd6a899c61a51057a717d0027717fd0a5 in cloudstack's branch 
refs/heads/CLOUDSTACK-7418 from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=18653f6 ]

CLOUDSTACK-7418 and CLOUDSTACK-7488 - Fixed LB removal if cert is applied


 Deleting a load balancer rule that has an SSL cert assigned to it does not 
 delete the mapping in the load_balancer_cert_map table
 -

 Key: CLOUDSTACK-7418
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7418
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Patrick D.

 This causes a Null Pointer Exception when listing the SSL certificates 
 because it tries to get the ID of a lbr that does not exist anymore.



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

[jira] [Commented] (CLOUDSTACK-7474) Failed to start MS with java7 version mismatch error

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

CLOUDSTACK-7474:Failed to start MS with java7 version mismatch error


 Failed to start MS with java7 version mismatch error
 

 Key: CLOUDSTACK-7474
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7474
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Rayees Namathponnan
Priority: Critical
 Fix For: 4.5.0


 Steps  to reproduce 
 Step 1: Deploy new RHEL 6.3 machine
 Step 2 : Install MS
 Step 3: run deploy script and start MS
 Result 
 Installation completed successfully,  both java7 and java got installed as 
 part of MS installation, but MS failed to start with below error 
 SEVERE: Null component 
 Catalina:type=JspMonitor,name=jsp,WebModule=//localhost/client,J2EEApplication=none,J2EEServer=none
 Sep 2, 2014 11:11:54 PM org.apache.catalina.startup.HostConfig deployDirectory
 SEVERE: Error deploying web application directory client
 java.lang.UnsupportedClassVersionError: 
 org/apache/cloudstack/spring/module/web/CloudStackContextLoaderListener : 
 Unsupported major.minor version 51.0 (unable to load class 
 org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener)
 at 
 org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2335)
 at 
 org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:976)
 at 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1451)
 at 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329)
 at 
 org.apache.catalina.startup.WebAnnotationSet.loadClassAnnotation(WebAnnotationSet.java:145)
 at 
 org.apache.catalina.startup.WebAnnotationSet.loadApplicationListenerAnnotations(WebAnnotationSet.java:73)
 at 
 org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:56)
 at 
 org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:297)
 at 
 org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1074)
 at 
 org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:261)
 at 
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
 at 
 org.apache.catalina.core.StandardContext.start(StandardContext.java:4377)
 at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
 at 
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
 at 
 org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
 at 
 org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
 at 
 org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
 at 
 org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
 at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
 Default JAva version in this machcne is java6,  while start MS, we need to 
 pick java7 from /usr/lib/jvm/jre-1.7.0 or $JAVA_HOME
 We need to fix this in classpath.conf
 export CLASSPATH
 if   [[ ! -d $JAVA_HOME  -d /usr/lib/jvm/jre-1.7.0 ]]; then
  export JAVA_HOME=/usr/lib/jvm/jre-1.7.0
 fi
 PATH=$JAVA_HOME/bin:/sbin:/usr/sbin:$PATH
 export PATH 



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

[jira] [Commented] (CLOUDSTACK-7396) [Automation] Failed to stop VPC router in KVM

2014-09-04 Thread Animesh Chaturvedi (JIRA) 

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

Animesh Chaturvedi commented on CLOUDSTACK-7396:


Rayees is this still happening?

 [Automation] Failed to stop VPC router in KVM
 -

 Key: CLOUDSTACK-7396
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7396
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: edison su
Priority: Blocker
 Fix For: 4.5.0

 Attachments: agent.rar, kvm.sql, management-server.rar


 This issue observed with latest automation run,  deploy a VPC router and stop 
 Virtual router stop fails with below exception 
 {noformat}
 lhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAABAAEC-XQAGVZpcn
 R1YWxNYWNoaW5lTWFuYWdlckltcGwA, cmdVersion: 0, status: IN_PROGRESS, 
 processStatus: 0, resultCode: 0, result: null, initMsid:
  29066118877352, completeMsid: null, lastUpdated: null, lastPolled: null, 
 created: Thu Aug 21 22:24:10 PDT 2014}, job origin
 :8131
 com.cloud.utils.exception.CloudRuntimeException: Unable to stop 
 VM[DomainRouter|r-761-VM]
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1523)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:1377)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:4594)
 at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4738)
 at 
 com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)
 2014-08-21 22:24:11,959 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Work-Job-Executor-28:ctx-8824da69 job-8131/job-8162) Comple
 te async job-8162, jobStatus: FAILED, resultCode: 0, result: 
 rO0ABXNyABpqYXZhLmxhbmcuUnVudGltZUV4Y2VwdGlvbp5fBkcKNIPlAgAAeHI
 AE2phdmEubGFuZy5FeGNlcHRpb27Q_R8-GjscxAIAAHhyABNqYXZhLmxhbmcuVGhyb3dhYmxl1cY1Jzl3uMsDAARMAAVjYXVzZXQAFUxqYXZhL2xhbmcvVGhyb3d
 hYmxlO0wADWRldGFpbE1lc3NhZ2V0ABJMamF2YS9sYW5nL1N0cmluZztbAApzdGFja1RyYWNldAAeW0xqYXZhL2xhbmcvU3RhY2tUcmFjZUVsZW1lbnQ7TAAUc3V
 wcHJlc3NlZEV4Y2VwdGlvbnN0ABBMamF2YS91dGlsL0xpc3Q7eHBxAH4AB3QAREpvYiBmYWlsZWQgZHVlIHRvIGV4Y2VwdGlvbiBVbmFibGUgdG8gc3RvcCBWTVt
 Eb21haW5Sb3V0ZXJ8ci03NjEtVk1ddXIAHltMamF2YS5sYW5nLlN0YWNrVHJhY2VFbGVtZW50OwJGKjw8_SI5AgAAeHANc3IAG2phdmEubGFuZy5TdGFja1R
 yYWNlRWxlbWVudGEJxZomNt2FAgAESQAKbGluZU51bWJlckwADmRlY2xhcmluZ0NsYXNzcQB-AARMAAhmaWxlTm
 2014-08-21 22:42:19,885 ERROR [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-149:ctx-5eeadd75 job-8131/job-8304) Unable to c
 omplete AsyncJobVO {id:8304, userId: 1, accountId: 1, instanceType: null, 
 instanceId: null, cmd: com.cloud.vm.VmWorkStop, cm
 dInfo: 
 rO0ABXNyABdjb20uY2xvdWQudm0uVm1Xb3JrU3RvcALQ4GymiWjjAgABWgAHY2xlYW51cHhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKA
 AlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAABAAEDBnQAGVZpc
 nR1YWxNYWNoaW5lTWFuYWdlckltcGwA,

[jira] [Commented] (CLOUDSTACK-7479) [LXC]need a check that LXC VM's root disk only goes to nfs or local storage even if ceph storage is also there

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

CLOUDSTACK-7478, CLOUDSTACK-7479: Check for correct storage pool type for ROOT 
and Data disks in LXC


 [LXC]need a check that LXC VM's root disk only goes to nfs or local storage 
 even if ceph storage is also there
 --

 Key: CLOUDSTACK-7479
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7479
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0


 Repro steps:
 1. Create a LXC zone with two primary storage one NFS and the other RBD  ceph
 2. Create a VM with both root and data disk.
 Bug:
 VM  creation fails as it tries to create root disk in Ceph.
 so we need to have certain type of check which force to create root disk only 
 on nfs and local . At the same time we also need to have a check which force 
 to create data disk only on LXC .



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

[jira] [Commented] (CLOUDSTACK-7478) [LXC] VM creation should fail when creating LXC VM with data disk and w/o having ceph as primary storage

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

CLOUDSTACK-7478, CLOUDSTACK-7479: Check for correct storage pool type for ROOT 
and Data disks in LXC


 [LXC] VM creation should fail when creating LXC VM with data disk and w/o 
 having ceph as primary storage
 

 Key: CLOUDSTACK-7478
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7478
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0

 Attachments: agent.log.tar.gz, ms.tar.gz


 Repro steps:
 1. Create a LXC zone with only nfs
 2. Create a VM  with data disk
 Bug:
 VM  creations passes without giving error that data disk needs ceph storage
 Even usage events for data disk is also generated.
 VM  shows no data disk with it
 dumxml of VM shows:
 domain type='lxc' id='11480'
   namei-2-21-VM/name
   uuid7da917bf-dd91-4185-92ce-a419b6a7e396/uuid
   descriptionCentOS 6.3 (64-bit)/description
   memory unit='KiB'524288/memory
   currentMemory unit='KiB'524288/currentMemory
   vcpu placement='static'1/vcpu
   cputune
 shares500/shares
   /cputune
   resource
 partition/machine/partition
   /resource
   os
 type arch='x86_64'exe/type
 init/sbin/init/init
   /os
   features
 acpi/
 apic/
 pae/
   /features
   cpu
   /cpu
   clock offset='utc'
 timer name='kvmclock' present='no'/
   /clock
   on_poweroffdestroy/on_poweroff
   on_rebootrestart/on_reboot
   on_crashdestroy/on_crash
   devices
 emulator/usr/libexec/libvirt_lxc/emulator
 filesystem type='mount' accessmode='passthrough'
   source 
 dir='/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/138ef448-03d7-4344-92a9-3e981b8826b6'/
   target dir='/'/
 /filesystem
 interface type='bridge'
   mac address='06:00:f8:00:00:06'/
   source bridge='brem1-30'/
   target dev='vnet1'/
   model type='virtio'/
   bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
   /bandwidth
 /interface
 serial type='pty'
   target port='0'/
 /serial
 console type='pty' tty='/dev/pts/0'
   source path='/dev/pts/0'/
   target type='lxc' port='0'/
   alias name='console0'/
 /console
 memballoon model='none'/
   /devices
   seclabel type='none' model='selinux'/
 /domain



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

[jira] [Resolved] (CLOUDSTACK-7478) [LXC] VM creation should fail when creating LXC VM with data disk and w/o having ceph as primary storage

2014-09-04 Thread Kishan Kavala (JIRA) 

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

Kishan Kavala resolved CLOUDSTACK-7478.
---
Resolution: Fixed

 [LXC] VM creation should fail when creating LXC VM with data disk and w/o 
 having ceph as primary storage
 

 Key: CLOUDSTACK-7478
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7478
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0

 Attachments: agent.log.tar.gz, ms.tar.gz


 Repro steps:
 1. Create a LXC zone with only nfs
 2. Create a VM  with data disk
 Bug:
 VM  creations passes without giving error that data disk needs ceph storage
 Even usage events for data disk is also generated.
 VM  shows no data disk with it
 dumxml of VM shows:
 domain type='lxc' id='11480'
   namei-2-21-VM/name
   uuid7da917bf-dd91-4185-92ce-a419b6a7e396/uuid
   descriptionCentOS 6.3 (64-bit)/description
   memory unit='KiB'524288/memory
   currentMemory unit='KiB'524288/currentMemory
   vcpu placement='static'1/vcpu
   cputune
 shares500/shares
   /cputune
   resource
 partition/machine/partition
   /resource
   os
 type arch='x86_64'exe/type
 init/sbin/init/init
   /os
   features
 acpi/
 apic/
 pae/
   /features
   cpu
   /cpu
   clock offset='utc'
 timer name='kvmclock' present='no'/
   /clock
   on_poweroffdestroy/on_poweroff
   on_rebootrestart/on_reboot
   on_crashdestroy/on_crash
   devices
 emulator/usr/libexec/libvirt_lxc/emulator
 filesystem type='mount' accessmode='passthrough'
   source 
 dir='/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/138ef448-03d7-4344-92a9-3e981b8826b6'/
   target dir='/'/
 /filesystem
 interface type='bridge'
   mac address='06:00:f8:00:00:06'/
   source bridge='brem1-30'/
   target dev='vnet1'/
   model type='virtio'/
   bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
   /bandwidth
 /interface
 serial type='pty'
   target port='0'/
 /serial
 console type='pty' tty='/dev/pts/0'
   source path='/dev/pts/0'/
   target type='lxc' port='0'/
   alias name='console0'/
 /console
 memballoon model='none'/
   /devices
   seclabel type='none' model='selinux'/
 /domain



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

[jira] [Resolved] (CLOUDSTACK-7479) [LXC]need a check that LXC VM's root disk only goes to nfs or local storage even if ceph storage is also there

2014-09-04 Thread Kishan Kavala (JIRA) 

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

Kishan Kavala resolved CLOUDSTACK-7479.
---
Resolution: Fixed

 [LXC]need a check that LXC VM's root disk only goes to nfs or local storage 
 even if ceph storage is also there
 --

 Key: CLOUDSTACK-7479
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7479
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0


 Repro steps:
 1. Create a LXC zone with two primary storage one NFS and the other RBD  ceph
 2. Create a VM with both root and data disk.
 Bug:
 VM  creation fails as it tries to create root disk in Ceph.
 so we need to have certain type of check which force to create root disk only 
 on nfs and local . At the same time we also need to have a check which force 
 to create data disk only on LXC .



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

[jira] [Created] (CLOUDSTACK-7489) Unable to expunge VM due to failing to revoke all static nat rules

2014-09-04 Thread Justyn Shull (JIRA) 
Justyn Shull created CLOUDSTACK-7489:


 Summary: Unable to expunge VM due to failing to revoke all static 
nat rules
 Key: CLOUDSTACK-7489
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7489
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.4.0
 Environment: Kernel: 2.6.32-358.14.1.el6.x86_64 #1 SMP Tue Jul 16 
23:51:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
OS: CentOS release 6.4 (Final)
CS RPMs:
cloudstack-management-4.4.0-NONOSS_3.el6.x86_64
cloudstack-common-4.4.0-NONOSS_3.el6.x86_64
cloudstack-cli-4.4.0-NONOSS_3.el6.x86_64
cloudstack-usage-4.4.0-NONOSS_3.el6.x86_64
cloudstack-awsapi-4.4.0-NONOSS_3.el6.x86_64

Cloudstack was upgraded from 3.0.6 originally 
Reporter: Justyn Shull


I've seen these errors a few times in the management-server.log now.   It has 
happened on a few different networks and ips, but we have not located a root 
cause for it yet.   It basically prevents the VM from being expunged.   

{code}
# grep 'ctx-2a7eee77' /var/log/cloudstack/management/management-server.log
2014-09-04 10:00:41,982 INFO  [c.c.v.UserVmManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Found 1 vms to expunge.
2014-09-04 10:00:41,994 WARN  [o.a.c.f.j.AsyncJobExecutionContext] 
(UserVm-Scavenger-10:ctx-2a7eee77) Job is executed without a context, setup 
psudo job for the executing thread
2014-09-04 10:00:42,160 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Sync job-170172 execution on object 
VmWorkJobQueue.6715
2014-09-04 10:00:42,170 WARN  [c.c.u.d.Merovingian2] 
(UserVm-Scavenger-10:ctx-2a7eee77) Was unable to find lock for the key 
vm_instance6715 and thread id 745113246
2014-09-04 10:00:45,678 DEBUG [c.c.c.CapacityManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) VM state transitted from :Expunging to 
Expunging with event: ExpungeOperationvm's original host id: 12 new host id: 
null host id before state transition: null
2014-09-04 10:00:45,680 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Destroying vm VM[User|i-258-6715-VM]
2014-09-04 10:00:45,681 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Cleaning up NICS
2014-09-04 10:00:45,681 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
(UserVm-Scavenger-10:ctx-2a7eee77) Cleaning network for vm: 6715
2014-09-04 10:00:45,688 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Cleaning up hypervisor data structures (ex. 
SRs in XenServer) for managed storage
2014-09-04 10:00:45,745 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
(UserVm-Scavenger-10:ctx-2a7eee77) Cleaning storage for vm: 6715
2014-09-04 10:00:45,759 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Expunged VM[User|i-258-6715-VM]
2014-09-04 10:00:45,759 DEBUG [c.c.v.UserVmManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Starting cleaning up vm 
VM[User|i-258-6715-VM] resources...
2014-09-04 10:00:45,830 DEBUG [c.c.n.f.FirewallManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) No firewall rules are found for vm id=6715
2014-09-04 10:00:45,885 DEBUG [c.c.v.UserVmManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Firewall rules are removed successfully as a 
part of vm id=6715 expunge
2014-09-04 10:00:45,896 DEBUG [c.c.n.r.RulesManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) No port forwarding rules are found for vm 
id=6715
2014-09-04 10:00:45,896 DEBUG [c.c.v.UserVmManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Port forwarding rules are removed 
successfully as a part of vm id=6715 expunge
2014-09-04 10:00:45,898 DEBUG [c.c.v.UserVmManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Removed vm id=6715 from all load balancers 
as a part of expunge process
2014-09-04 10:00:45,914 DEBUG [c.c.n.r.RulesManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Revoking all Firewallrules as a part of 
disabling static nat for public IP id=235
2014-09-04 10:00:45,940 DEBUG [c.c.n.f.FirewallManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Releasing 0 firewall rules for ip id=235
2014-09-04 10:00:45,943 DEBUG [c.c.n.f.FirewallManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) There are no firewall rules to apply
2014-09-04 10:00:45,945 DEBUG [c.c.n.f.FirewallManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Successfully released firewall rules for ip 
id=235 and # of rules now = 0
2014-09-04 10:00:45,969 DEBUG [c.c.n.r.RulesManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Releasing 0 port forwarding rules for ip 
id=235
2014-09-04 10:00:45,972 DEBUG [c.c.n.r.RulesManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) Releasing 0 static nat rules for ip id=235
2014-09-04 10:00:45,999 DEBUG [c.c.n.r.RulesManagerImpl] 
(UserVm-Scavenger-10:ctx-2a7eee77) There are no port forwarding rules to apply 
for ip id=235
2014-09-04 10:00:46,001 DEBUG [c.c.n.r.RulesManagerImpl]

[jira] [Commented] (CLOUDSTACK-7468) NetScaler SSL Termination does not handle Projects as expected

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

CLOUDSTACK-7468: Fixed the NetScaler SSL Termination behavior with Projects

Signed-off-by: Will Stevens wstev...@cloudops.com


 NetScaler SSL Termination does not handle Projects as expected
 --

 Key: CLOUDSTACK-7468
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7468
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.5.0, 4.4.1
Reporter: Will Stevens
Assignee: Will Stevens
 Attachments: 
 CLOUDSTACK-7468-Fixed-NetScaler-SSL-Termination-for-Projects.patch


 Currently the 'uploadSslCert' api call does not take any details about who 
 should own the SSL Cert.  It basically assigns the cert to the caller and 
 thats it.
 This breaks the expected behavior for projects and also does not allow for an 
 admin to upload certificates on behalf of one of their users.
 This fix should not adjust the database entities at all, but should allow the 
 API calls to handle the additional cases.
 The following changes should be made:
 - If 'uploadSslCert' is called without any account details, it should behave 
 how it does now and assign the cert to the caller.
 - If 'uploadSslCert' includes option 'account' and 'domainId' fields, the 
 uploaded cert will be applied to that account.
 - If 'uploadSslCert' includes a 'projectId', then the cert is applied to that 
 project.
 - The 'listSslCerts' api should also take an optional 'projectid' field to 
 list the ssl certs associated with that project.  
 - The api response for both 'uploadSslCert' and 'listSslCerts' should be 
 updated to include additional information about the account or project as 
 well as the domain in which the cert is assigned.



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

[jira] [Commented] (CLOUDSTACK-7468) NetScaler SSL Termination does not handle Projects as expected

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

Merge branch 'origin/CLOUDSTACK-7468'


 NetScaler SSL Termination does not handle Projects as expected
 --

 Key: CLOUDSTACK-7468
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7468
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.5.0, 4.4.1
Reporter: Will Stevens
Assignee: Will Stevens
 Attachments: 
 CLOUDSTACK-7468-Fixed-NetScaler-SSL-Termination-for-Projects.patch


 Currently the 'uploadSslCert' api call does not take any details about who 
 should own the SSL Cert.  It basically assigns the cert to the caller and 
 thats it.
 This breaks the expected behavior for projects and also does not allow for an 
 admin to upload certificates on behalf of one of their users.
 This fix should not adjust the database entities at all, but should allow the 
 API calls to handle the additional cases.
 The following changes should be made:
 - If 'uploadSslCert' is called without any account details, it should behave 
 how it does now and assign the cert to the caller.
 - If 'uploadSslCert' includes option 'account' and 'domainId' fields, the 
 uploaded cert will be applied to that account.
 - If 'uploadSslCert' includes a 'projectId', then the cert is applied to that 
 project.
 - The 'listSslCerts' api should also take an optional 'projectid' field to 
 list the ssl certs associated with that project.  
 - The api response for both 'uploadSslCert' and 'listSslCerts' should be 
 updated to include additional information about the account or project as 
 well as the domain in which the cert is assigned.



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

[jira] [Commented] (CLOUDSTACK-7488) Releasing an IP address that has a LBR with a SSL certificate does not remove the LBR-SSL mapping (which breaks SSL Cert listing)

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

CLOUDSTACK-7418 and CLOUDSTACK-7488 - Fixed LB removal if cert is applied


 Releasing an IP address that has a LBR with a SSL certificate does not remove 
 the LBR-SSL mapping (which breaks SSL Cert listing)
 -

 Key: CLOUDSTACK-7488
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7488
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Patrick D.

 In relation to CLOUDSTACK-7418



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

[jira] [Commented] (CLOUDSTACK-7418) Deleting a load balancer rule that has an SSL cert assigned to it does not delete the mapping in the load_balancer_cert_map table

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

CLOUDSTACK-7418 and CLOUDSTACK-7488 - Fixed LB removal if cert is applied


 Deleting a load balancer rule that has an SSL cert assigned to it does not 
 delete the mapping in the load_balancer_cert_map table
 -

 Key: CLOUDSTACK-7418
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7418
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Patrick D.

 This causes a Null Pointer Exception when listing the SSL certificates 
 because it tries to get the ID of a lbr that does not exist anymore.



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

[jira] [Commented] (CLOUDSTACK-7418) Deleting a load balancer rule that has an SSL cert assigned to it does not delete the mapping in the load_balancer_cert_map table

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

CLOUDSTACK-7418 and CLOUDSTACK-7488 - Fixed LB removal if cert is associated


 Deleting a load balancer rule that has an SSL cert assigned to it does not 
 delete the mapping in the load_balancer_cert_map table
 -

 Key: CLOUDSTACK-7418
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7418
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Patrick D.

 This causes a Null Pointer Exception when listing the SSL certificates 
 because it tries to get the ID of a lbr that does not exist anymore.



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

[jira] [Commented] (CLOUDSTACK-7488) Releasing an IP address that has a LBR with a SSL certificate does not remove the LBR-SSL mapping (which breaks SSL Cert listing)

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

CLOUDSTACK-7418 and CLOUDSTACK-7488 - Fixed LB removal if cert is associated


 Releasing an IP address that has a LBR with a SSL certificate does not remove 
 the LBR-SSL mapping (which breaks SSL Cert listing)
 -

 Key: CLOUDSTACK-7488
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7488
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Patrick D.

 In relation to CLOUDSTACK-7418



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

[jira] [Resolved] (CLOUDSTACK-7468) NetScaler SSL Termination does not handle Projects as expected

2014-09-04 Thread Will Stevens (JIRA) 

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

Will Stevens resolved CLOUDSTACK-7468.
--
   Resolution: Fixed
Fix Version/s: 4.4.1
   4.5.0

This fix has been merged into the 4.4 branch.  I have also pushed this fix into 
the master branch (4.5).

 NetScaler SSL Termination does not handle Projects as expected
 --

 Key: CLOUDSTACK-7468
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7468
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.5.0, 4.4.1
Reporter: Will Stevens
Assignee: Will Stevens
 Fix For: 4.5.0, 4.4.1

 Attachments: 
 CLOUDSTACK-7468-Fixed-NetScaler-SSL-Termination-for-Projects.patch


 Currently the 'uploadSslCert' api call does not take any details about who 
 should own the SSL Cert.  It basically assigns the cert to the caller and 
 thats it.
 This breaks the expected behavior for projects and also does not allow for an 
 admin to upload certificates on behalf of one of their users.
 This fix should not adjust the database entities at all, but should allow the 
 API calls to handle the additional cases.
 The following changes should be made:
 - If 'uploadSslCert' is called without any account details, it should behave 
 how it does now and assign the cert to the caller.
 - If 'uploadSslCert' includes option 'account' and 'domainId' fields, the 
 uploaded cert will be applied to that account.
 - If 'uploadSslCert' includes a 'projectId', then the cert is applied to that 
 project.
 - The 'listSslCerts' api should also take an optional 'projectid' field to 
 list the ssl certs associated with that project.  
 - The api response for both 'uploadSslCert' and 'listSslCerts' should be 
 updated to include additional information about the account or project as 
 well as the domain in which the cert is assigned.



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

[jira] [Updated] (CLOUDSTACK-6063) CLONE - Non windows instances are created on XenServer with a vcpu-max above supported xenserver limits

2014-09-04 Thread Nitin Mehta (JIRA) 

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

Nitin Mehta updated CLOUDSTACK-6063:

Fix Version/s: (was: Future)
   4.5.0

 CLONE - Non windows instances are created on XenServer with a vcpu-max above 
 supported xenserver limits
 ---

 Key: CLOUDSTACK-6063
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6063
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: XenServer
Affects Versions: Future, 4.2.1, 4.3.0
Reporter: Nitin Mehta
Assignee: Harikrishna Patnala
Priority: Critical
 Fix For: 4.5.0


 CitrixResourceBase.java contains a hardcoded value for vcpusmax for non 
 windows instances:
 if (guestOsTypeName.toLowerCase().contains(windows)) {
 vmr.VCPUsMax = (long) vmSpec.getCpus();
 } else {
 vmr.VCPUsMax = 32L;
 }
 For all currently available versions of XenServer the limit is 16vcpus:
 http://support.citrix.com/servlet/KbServlet/download/28909-102-664115/XenServer-6.0-Configuration-Limits.pdf
 http://support.citrix.com/servlet/KbServlet/download/32312-102-704653/CTX134789%20-%20XenServer%206.1.0_Configuration%20Limits.pdf
 http://support.citrix.com/servlet/KbServlet/download/34966-102-706122/CTX137837_XenServer%206_2_0_Configuration%20Limits.pdf
 In addition there seems to be a limit to the total amount of assigned vpcus 
 on a XenServer.
 The impact of this bug is that xapi becomes unstable and keeps losing it's 
 master_connection because the POST to the /remote_db_access is bigger then 
 it's limit of 200K. This basically renders a pool slave unmanageable. 
 If you would look at the running instances using xentop you will see hosts 
 reporting with 32 vcpus
 Below the relevant portion of the xensource.log that shows the effect of the 
 bug:
 [20140204T13:52:17.264Z|debug|xenserverhost1|144 inet-RPC|host.call_plugin 
 R:e58e985539ab|master_connection] stunnel: Using commandline: 
 /usr/sbin/stunnel -fd f3b8bb12-4e03-b47a-0dc5-85ad5aef79e6
 [20140204T13:52:17.269Z|debug|xenserverhost1|144 inet-RPC|host.call_plugin 
 R:e58e985539ab|master_connection] stunnel: stunnel has pidty: (FEFork 
 (43,30540))
 [20140204T13:52:17.269Z|debug|xenserverhost1|144 inet-RPC|host.call_plugin 
 R:e58e985539ab|master_connection] stunnel: stunnel start
 [20140204T13:52:17.269Z| info|xenserverhost1|144 inet-RPC|host.call_plugin 
 R:e58e985539ab|master_connection] stunnel connected pid=30540 fd=40
 [20140204T13:52:17.346Z|error|xenserverhost1|144 inet-RPC|host.call_plugin 
 R:e58e985539ab|master_connection] Received HTTP error 500 ({ method = POST; 
 uri = /remote_db_access; query = [  ]; content_length = [ 315932 ]; transfer 
 encoding = ; version = 1.1; cookie = [ 
 pool_secret=386bbf39-8710-4d2d-f452-9725d79c2393/aa7bcda9-8ebb-0cef-bb77-c6b496c5d859/1f928d82-7a20-9117-dd30-f96c7349b16e
  ]; task = ; subtask_of = ; content-type = ; user_agent = xapi/1.9 }) from 
 master. This suggests our master address is wrong. Sleeping for 60s and then 
 restarting.
 [20140204T13:53:18.620Z|error|xenserverhost1|10|dom0 networking update 
 D:5c5376f0da6c|master_connection] Caught Master_connection.Goto_handler
 [20140204T13:53:18.620Z|debug|xenserverhost1|10|dom0 networking update 
 D:5c5376f0da6c|master_connection] Connection to master died. I will continue 
 to retry indefinitely (supressing future logging of this message).
 [20140204T13:53:18.620Z|error|xenserverhost1|10|dom0 networking update 
 D:5c5376f0da6c|master_connection] Connection to master died. I will continue 
 to retry indefinitely (supressing future logging of this message).
 [20140204T13:53:18.620Z|debug|xenserverhost1|10|dom0 networking update 
 D:5c5376f0da6c|master_connection] Sleeping 2.00 seconds before retrying 
 master connection...
 [20140204T13:53:20.627Z|debug|xenserverhost1|10|dom0 networking update 
 D:5c5376f0da6c|master_connection] stunnel: Using commandline: 
 /usr/sbin/stunnel -fd 3c8aed8e-1fce-be7c-09f8-b45cdc40a1f5
 [20140204T13:53:20.632Z|debug|xenserverhost1|10|dom0 networking update 
 D:5c5376f0da6c|master_connection] stunnel: stunnel has pidty: (FEFork 
 (23,31207))
 [20140204T13:53:20.632Z|debug|xenserverhost1|10|dom0 networking update 
 D:5c5376f0da6c|master_connection] stunnel: stunnel start
 [20140204T13:53:20.632Z| info|xenserverhost1|10|dom0 networking update 
 D:5c5376f0da6c|master_connection] stunnel connected pid=31207 fd=20
 [20140204T13:53:28.874Z|error|xenserverhost1|4 
 unix-RPC|session.login_with_password D:2e7664ad69ed|master_connection] Caught 
 Master_connection.Goto_handler
 [20140204T13:53:28.874Z|debug|xenserverhost1|4

[jira] [Updated] (CLOUDSTACK-7482) Ajax calls in mgmt UI causing log pollution

2014-09-04 Thread Kedron Touvell (JIRA) 

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

Kedron Touvell updated CLOUDSTACK-7482:
---
Description: 
Many of the ajax calls in the mgmt UI are specifying a listAll parameter, 
despite the fact that the underlying API call does not support listAll.  This 
is causing a decent amount of log pollution:

{quote}
2014-09-03 10:54:21,475 WARN  [c.c.a.d.ParamGenericValidationWorker] 
(catalina-exec-8:ctx-aefb6d5e ctx-08b63c18) Received unknown parameters for 
command listImageStores. Unknown parameters : listall type
{quote}

These parameters are set in {{ui/scripts/system.js}}, for example:

{noformat}
systemVmCount: function (data) {
$.ajax({
url: createURL('listSystemVms'),
data: {
listAll: true,
{noformat}

Here's the list of API calls that I see generating warnings:

* listClusters
* listHosts
* listImageStores
* listNetworkOfferings
* listPods
* listRegions
* listServiceOfferings
* listStoragePools
* listSystemVms
* listZones

One more to add...listDomains is being called with a parentdomainid parameter, 
leading to the following warning:

{quote}
2014-09-04 11:59:01,217 WARN  [c.c.a.d.ParamGenericValidationWorker] 
(catalina-exec-5:ctx-c85dc843 ctx-647a43c1 ctx-bcd4e41b) Received unknown 
parameters for command listDomains. Unknown parameters : parentdomainid
{quote}


  was:
Many of the ajax calls in the mgmt UI are specifying a listAll parameter, 
despite the fact that the underlying API call does not support listAll.  This 
is causing a decent amount of log pollution:

{quote}
2014-09-03 10:54:21,475 WARN  [c.c.a.d.ParamGenericValidationWorker] 
(catalina-exec-8:ctx-aefb6d5e ctx-08b63c18) Received unknown parameters for 
command listImageStores. Unknown parameters : listall type
{quote}

These parameters are set in {{ui/scripts/system.js}}, for example:

{noformat}
systemVmCount: function (data) {
$.ajax({
url: createURL('listSystemVms'),
data: {
listAll: true,
{noformat}

Here's the list of API calls that I see generating warnings:

* listClusters
* listHosts
* listImageStores
* listNetworkOfferings
* listPods
* listRegions
* listServiceOfferings
* listStoragePools
* listSystemVms
* listZones


 Ajax calls in mgmt UI causing log pollution
 ---

 Key: CLOUDSTACK-7482
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7482
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.4.0
Reporter: Kedron Touvell
Priority: Minor

 Many of the ajax calls in the mgmt UI are specifying a listAll parameter, 
 despite the fact that the underlying API call does not support listAll.  This 
 is causing a decent amount of log pollution:
 {quote}
 2014-09-03 10:54:21,475 WARN  [c.c.a.d.ParamGenericValidationWorker] 
 (catalina-exec-8:ctx-aefb6d5e ctx-08b63c18) Received unknown parameters for 
 command listImageStores. Unknown parameters : listall type
 {quote}
 These parameters are set in {{ui/scripts/system.js}}, for example:
 {noformat}
 systemVmCount: function (data) {
 $.ajax({
 url: createURL('listSystemVms'),
 data: {
 listAll: true,
 {noformat}
 Here's the list of API calls that I see generating warnings:
 * listClusters
 * listHosts
 * listImageStores
 * listNetworkOfferings
 * listPods
 * listRegions
 * listServiceOfferings
 * listStoragePools
 * listSystemVms
 * listZones
 One more to add...listDomains is being called with a parentdomainid 
 parameter, leading to the following warning:
 {quote}
 2014-09-04 11:59:01,217 WARN  [c.c.a.d.ParamGenericValidationWorker] 
 (catalina-exec-5:ctx-c85dc843 ctx-647a43c1 ctx-bcd4e41b) Received unknown 
 parameters for command listDomains. Unknown parameters : parentdomainid
 {quote}



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

[jira] [Commented] (CLOUDSTACK-7488) Releasing an IP address that has a LBR with a SSL certificate does not remove the LBR-SSL mapping (which breaks SSL Cert listing)

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit 6c501dba45468d216f0d3d41adaa8e05cc083321 in cloudstack's branch 
refs/heads/4.4 from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6c501db ]

CLOUDSTACK-7418 and CLOUDSTACK-7488 - Fixed LB removal if cert is associated


 Releasing an IP address that has a LBR with a SSL certificate does not remove 
 the LBR-SSL mapping (which breaks SSL Cert listing)
 -

 Key: CLOUDSTACK-7488
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7488
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Patrick D.

 In relation to CLOUDSTACK-7418



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

[jira] [Commented] (CLOUDSTACK-7418) Deleting a load balancer rule that has an SSL cert assigned to it does not delete the mapping in the load_balancer_cert_map table

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit 6c501dba45468d216f0d3d41adaa8e05cc083321 in cloudstack's branch 
refs/heads/4.4 from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6c501db ]

CLOUDSTACK-7418 and CLOUDSTACK-7488 - Fixed LB removal if cert is associated


 Deleting a load balancer rule that has an SSL cert assigned to it does not 
 delete the mapping in the load_balancer_cert_map table
 -

 Key: CLOUDSTACK-7418
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7418
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Patrick D.

 This causes a Null Pointer Exception when listing the SSL certificates 
 because it tries to get the ID of a lbr that does not exist anymore.



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

[jira] [Commented] (CLOUDSTACK-7488) Releasing an IP address that has a LBR with a SSL certificate does not remove the LBR-SSL mapping (which breaks SSL Cert listing)

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit 6c501dba45468d216f0d3d41adaa8e05cc083321 in cloudstack's branch 
refs/heads/hotfix/4.4/upgradepath-431to441 from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6c501db ]

CLOUDSTACK-7418 and CLOUDSTACK-7488 - Fixed LB removal if cert is associated


 Releasing an IP address that has a LBR with a SSL certificate does not remove 
 the LBR-SSL mapping (which breaks SSL Cert listing)
 -

 Key: CLOUDSTACK-7488
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7488
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Patrick D.

 In relation to CLOUDSTACK-7418



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

[jira] [Commented] (CLOUDSTACK-7418) Deleting a load balancer rule that has an SSL cert assigned to it does not delete the mapping in the load_balancer_cert_map table

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

Commit 6c501dba45468d216f0d3d41adaa8e05cc083321 in cloudstack's branch 
refs/heads/hotfix/4.4/upgradepath-431to441 from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6c501db ]

CLOUDSTACK-7418 and CLOUDSTACK-7488 - Fixed LB removal if cert is associated


 Deleting a load balancer rule that has an SSL cert assigned to it does not 
 delete the mapping in the load_balancer_cert_map table
 -

 Key: CLOUDSTACK-7418
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7418
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Patrick D.

 This causes a Null Pointer Exception when listing the SSL certificates 
 because it tries to get the ID of a lbr that does not exist anymore.



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

[jira] [Assigned] (CLOUDSTACK-6945) Null pointer exception when starting a VM that had its template deleted

2014-09-04 Thread Rohit Yadav (JIRA) 

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

Rohit Yadav reassigned CLOUDSTACK-6945:
---

Assignee: (was: Rohit Yadav)

 Null pointer exception when starting a VM that had its template deleted
 ---

 Key: CLOUDSTACK-6945
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6945
 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
 Environment: Hosts are Debian 7.4.0 with Xen hypervisor e Xen Cloud 
 Platform packages installed and properly configured.
Reporter: Rafael Weingartner
Priority: Minor
 Fix For: 4.5.0, 4.4.1


 It seems that you have a bug in CS 4.3.0(and probably previous versions?) 
 when starting a machine that was created from a template that has been 
 deleted.
 There will happen a null pointer exception in 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart:
 “858 -if (volTemplateId != null  volTemplateId.longValue() != 
 template.getId())”
 The object, “template” is going to be null, because in:
 “811 -  VirtualMachineTemplate template = 
 _entityMgr.findById(VirtualMachineTemplate.class, vm.getTemplateId());”
 The findById, will add a where clause, looking for template that have the 
 column removed that is null, therefore It will return a null object.



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

[jira] [Updated] (CLOUDSTACK-6945) Null pointer exception when starting a VM that had its template deleted

2014-09-04 Thread Rohit Yadav (JIRA) 

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

Rohit Yadav updated CLOUDSTACK-6945:

Fix Version/s: (was: 4.3.1)
   4.4.1
   4.5.0

 Null pointer exception when starting a VM that had its template deleted
 ---

 Key: CLOUDSTACK-6945
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6945
 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
 Environment: Hosts are Debian 7.4.0 with Xen hypervisor e Xen Cloud 
 Platform packages installed and properly configured.
Reporter: Rafael Weingartner
Assignee: Rohit Yadav
Priority: Minor
 Fix For: 4.5.0, 4.4.1


 It seems that you have a bug in CS 4.3.0(and probably previous versions?) 
 when starting a machine that was created from a template that has been 
 deleted.
 There will happen a null pointer exception in 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart:
 “858 -if (volTemplateId != null  volTemplateId.longValue() != 
 template.getId())”
 The object, “template” is going to be null, because in:
 “811 -  VirtualMachineTemplate template = 
 _entityMgr.findById(VirtualMachineTemplate.class, vm.getTemplateId());”
 The findById, will add a where clause, looking for template that have the 
 column removed that is null, therefore It will return a null object.



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

[jira] [Updated] (CLOUDSTACK-7490) UI Templates detailView Zones tab click a row in the listing wrong template+zone combination is shown.

2014-09-04 Thread Jessica Wang (JIRA) 

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

Jessica Wang updated CLOUDSTACK-7490:
-
Attachment: 2_before_UI_fix.PNG
1_before_UI_fix.PNG

 UI  Templates  detailView  Zones tab  click a row in the listing  
 wrong template+zone combination is shown.
 

 Key: CLOUDSTACK-7490
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7490
 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
 Attachments: 1_before_UI_fix.PNG, 2_before_UI_fix.PNG


 steps:
 1) click Templates
 2) click a row from the listing (e.g. template CentOS 5.6)
 3) detailView slides up
 4) click Zones tab
 5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
 6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
 5.6).
 Please see attached screenshots 1_before_UI_fix.PNG, 2_before_UI_fix.PNG.



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

[jira] [Updated] (CLOUDSTACK-7490) UI Templates menu (listing) select a template from listing Details tab Zones tab (listing) select a zone from listing Details tab wrong template+zone

2014-09-04 Thread Jessica Wang (JIRA) 

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

Jessica Wang updated CLOUDSTACK-7490:
-
Summary: UI  Templates menu (listing)  select a template from listing  
Details tab  Zones tab (listing)  select a zone from listing  Details tab  
wrong template+zone combination is shown.  (was: UI  Templates  detailView 
 Zones tab  click a row in the listing  wrong template+zone combination 
is shown.)

 UI  Templates menu (listing)  select a template from listing  Details tab 
  Zones tab (listing)  select a zone from listing  Details tab  wrong 
 template+zone combination is shown.
 ---

 Key: CLOUDSTACK-7490
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7490
 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
 Attachments: 1_before_UI_fix.PNG, 2_before_UI_fix.PNG


 steps:
 1) click Templates
 2) click a row from the listing (e.g. template CentOS 5.6)
 3) detailView slides up
 4) click Zones tab
 5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
 6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
 5.6).
 Please see attached screenshots 1_before_UI_fix.PNG, 2_before_UI_fix.PNG.



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

[jira] [Commented] (CLOUDSTACK-7490) UI Templates menu (listing) select a template from listing Details tab Zones tab (listing) select a zone from listing Details tab wrong template+zon

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

CLOUDSTACK-7490: UI  Templates menu (listing)  select a template from listing 
 Details tab  Zones tab (listing)  select a zone from listing  Details tab 
 fix a bug that wrong template+zone combination was shown.


 UI  Templates menu (listing)  select a template from listing  Details tab 
  Zones tab (listing)  select a zone from listing  Details tab  wrong 
 template+zone combination is shown.
 ---

 Key: CLOUDSTACK-7490
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7490
 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
 Attachments: 1_before_UI_fix.PNG, 2_before_UI_fix.PNG


 steps:
 1) click Templates
 2) click a row from the listing (e.g. template CentOS 5.6)
 3) detailView slides up
 4) click Zones tab
 5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
 6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
 5.6).
 Please see attached screenshots 1_before_UI_fix.PNG, 2_before_UI_fix.PNG.



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

[jira] [Updated] (CLOUDSTACK-7490) UI Templates menu (listing) select a template from listing Details tab Zones tab (listing) select a zone from listing Details tab wrong template+zone

2014-09-04 Thread Jessica Wang (JIRA) 

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

Jessica Wang updated CLOUDSTACK-7490:
-
Attachment: (was: 1_before_UI_fix.PNG)

 UI  Templates menu (listing)  select a template from listing  Details tab 
  Zones tab (listing)  select a zone from listing  Details tab  wrong 
 template+zone combination is shown.
 ---

 Key: CLOUDSTACK-7490
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7490
 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

 steps:
 1) click Templates
 2) click a row from the listing (e.g. template CentOS 5.6)
 3) detailView slides up
 4) click Zones tab
 5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
 6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
 5.6).
 Please see attached screenshots 1_before_UI_fix.PNG, 2_before_UI_fix.PNG.



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

[jira] [Updated] (CLOUDSTACK-7490) UI Templates menu (listing) select a template from listing Details tab Zones tab (listing) select a zone from listing Details tab wrong template+zone

2014-09-04 Thread Jessica Wang (JIRA) 

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

Jessica Wang updated CLOUDSTACK-7490:
-
Attachment: (was: 2_before_UI_fix.PNG)

 UI  Templates menu (listing)  select a template from listing  Details tab 
  Zones tab (listing)  select a zone from listing  Details tab  wrong 
 template+zone combination is shown.
 ---

 Key: CLOUDSTACK-7490
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7490
 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

 steps:
 1) click Templates
 2) click a row from the listing (e.g. template CentOS 5.6)
 3) detailView slides up
 4) click Zones tab
 5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
 6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
 5.6).
 Please see attached screenshots 1_before_UI_fix.PNG, 2_before_UI_fix.PNG.



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

[jira] [Updated] (CLOUDSTACK-7490) UI Templates menu (listing) select a template from listing Details tab Zones tab (listing) select a zone from listing Details tab wrong template+zone

2014-09-04 Thread Jessica Wang (JIRA) 

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

Jessica Wang updated CLOUDSTACK-7490:
-
Description: 
steps:
1) click Templates
2) click a row from the listing (e.g. template CentOS 5.6)
3) detailView slides up
4) click Zones tab
5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
5.6).

Please see attached screenshots before_UI_fix_1.PNG, before_UI_fix_2.PNG.

  was:
steps:
1) click Templates
2) click a row from the listing (e.g. template CentOS 5.6)
3) detailView slides up
4) click Zones tab
5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
5.6).

Please see attached screenshots 1_before_UI_fix.PNG, 2_before_UI_fix.PNG.


 UI  Templates menu (listing)  select a template from listing  Details tab 
  Zones tab (listing)  select a zone from listing  Details tab  wrong 
 template+zone combination is shown.
 ---

 Key: CLOUDSTACK-7490
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7490
 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
 Attachments: before_UI_fix_1.PNG, before_UI_fix_2.PNG


 steps:
 1) click Templates
 2) click a row from the listing (e.g. template CentOS 5.6)
 3) detailView slides up
 4) click Zones tab
 5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
 6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
 5.6).
 Please see attached screenshots before_UI_fix_1.PNG, before_UI_fix_2.PNG.



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

[jira] [Updated] (CLOUDSTACK-7490) UI Templates menu (listing) select a template from listing Details tab Zones tab (listing) select a zone from listing Details tab wrong template+zone

2014-09-04 Thread Jessica Wang (JIRA) 

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

Jessica Wang updated CLOUDSTACK-7490:
-
Attachment: before_UI_fix_2.PNG
before_UI_fix_1.PNG

 UI  Templates menu (listing)  select a template from listing  Details tab 
  Zones tab (listing)  select a zone from listing  Details tab  wrong 
 template+zone combination is shown.
 ---

 Key: CLOUDSTACK-7490
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7490
 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
 Attachments: before_UI_fix_1.PNG, before_UI_fix_2.PNG


 steps:
 1) click Templates
 2) click a row from the listing (e.g. template CentOS 5.6)
 3) detailView slides up
 4) click Zones tab
 5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
 6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
 5.6).
 Please see attached screenshots before_UI_fix_1.PNG, before_UI_fix_2.PNG.



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

[jira] [Updated] (CLOUDSTACK-7490) UI Templates menu (listing) select a template from listing Details tab Zones tab (listing) select a zone from listing Details tab wrong template+zone

2014-09-04 Thread Jessica Wang (JIRA) 

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

Jessica Wang updated CLOUDSTACK-7490:
-
Attachment: after_UI_fix_2.PNG
after_UI_fix_1.PNG

 UI  Templates menu (listing)  select a template from listing  Details tab 
  Zones tab (listing)  select a zone from listing  Details tab  wrong 
 template+zone combination is shown.
 ---

 Key: CLOUDSTACK-7490
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7490
 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
 Attachments: after_UI_fix_1.PNG, after_UI_fix_2.PNG, 
 before_UI_fix_1.PNG, before_UI_fix_2.PNG


 steps:
 1) click Templates
 2) click a row from the listing (e.g. template CentOS 5.6)
 3) detailView slides up
 4) click Zones tab
 5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
 6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
 5.6).
 Please see attached screenshots before_UI_fix_1.PNG, before_UI_fix_2.PNG.



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

[jira] [Commented] (CLOUDSTACK-7490) UI Templates menu (listing) select a template from listing Details tab Zones tab (listing) select a zone from listing Details tab wrong template+zon

2014-09-04 Thread Jessica Wang (JIRA) 

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

Jessica Wang commented on CLOUDSTACK-7490:
--

fixed.

As attached screenshots after_UI_fix_1, after_UI_fix_2.

 UI  Templates menu (listing)  select a template from listing  Details tab 
  Zones tab (listing)  select a zone from listing  Details tab  wrong 
 template+zone combination is shown.
 ---

 Key: CLOUDSTACK-7490
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7490
 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
 Attachments: before_UI_fix_1.PNG, before_UI_fix_2.PNG


 steps:
 1) click Templates
 2) click a row from the listing (e.g. template CentOS 5.6)
 3) detailView slides up
 4) click Zones tab
 5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
 6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
 5.6).
 Please see attached screenshots before_UI_fix_1.PNG, before_UI_fix_2.PNG.



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

[jira] [Closed] (CLOUDSTACK-7490) UI Templates menu (listing) select a template from listing Details tab Zones tab (listing) select a zone from listing Details tab wrong template+zone

2014-09-04 Thread Jessica Wang (JIRA) 

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

Jessica Wang closed CLOUDSTACK-7490.


 UI  Templates menu (listing)  select a template from listing  Details tab 
  Zones tab (listing)  select a zone from listing  Details tab  wrong 
 template+zone combination is shown.
 ---

 Key: CLOUDSTACK-7490
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7490
 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
 Attachments: after_UI_fix_1.PNG, after_UI_fix_2.PNG, 
 before_UI_fix_1.PNG, before_UI_fix_2.PNG


 steps:
 1) click Templates
 2) click a row from the listing (e.g. template CentOS 5.6)
 3) detailView slides up
 4) click Zones tab
 5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
 6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
 5.6).
 As attached screenshots before_UI_fix_1.PNG, before_UI_fix_2.PNG.



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

[jira] [Updated] (CLOUDSTACK-7490) UI Templates menu (listing) select a template from listing Details tab Zones tab (listing) select a zone from listing Details tab wrong template+zone

2014-09-04 Thread Jessica Wang (JIRA) 

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

Jessica Wang updated CLOUDSTACK-7490:
-
Description: 
steps:
1) click Templates
2) click a row from the listing (e.g. template CentOS 5.6)
3) detailView slides up
4) click Zones tab
5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
5.6).

As attached screenshots before_UI_fix_1.PNG, before_UI_fix_2.PNG.

  was:
steps:
1) click Templates
2) click a row from the listing (e.g. template CentOS 5.6)
3) detailView slides up
4) click Zones tab
5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
5.6).

Please see attached screenshots before_UI_fix_1.PNG, before_UI_fix_2.PNG.


 UI  Templates menu (listing)  select a template from listing  Details tab 
  Zones tab (listing)  select a zone from listing  Details tab  wrong 
 template+zone combination is shown.
 ---

 Key: CLOUDSTACK-7490
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7490
 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
 Attachments: after_UI_fix_1.PNG, after_UI_fix_2.PNG, 
 before_UI_fix_1.PNG, before_UI_fix_2.PNG


 steps:
 1) click Templates
 2) click a row from the listing (e.g. template CentOS 5.6)
 3) detailView slides up
 4) click Zones tab
 5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
 6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
 5.6).
 As attached screenshots before_UI_fix_1.PNG, before_UI_fix_2.PNG.



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

[jira] [Resolved] (CLOUDSTACK-7490) UI Templates menu (listing) select a template from listing Details tab Zones tab (listing) select a zone from listing Details tab wrong template+zone

2014-09-04 Thread Jessica Wang (JIRA) 

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

Jessica Wang resolved CLOUDSTACK-7490.
--
Resolution: Fixed

 UI  Templates menu (listing)  select a template from listing  Details tab 
  Zones tab (listing)  select a zone from listing  Details tab  wrong 
 template+zone combination is shown.
 ---

 Key: CLOUDSTACK-7490
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7490
 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
 Attachments: after_UI_fix_1.PNG, after_UI_fix_2.PNG, 
 before_UI_fix_1.PNG, before_UI_fix_2.PNG


 steps:
 1) click Templates
 2) click a row from the listing (e.g. template CentOS 5.6)
 3) detailView slides up
 4) click Zones tab
 5) click a row from the listing (e.g. zone jw2 + template CentOS 5.6)
 6) detailView slides up = wrong info is shown (zone jw1 + template CentOS 
 5.6).
 As attached screenshots before_UI_fix_1.PNG, before_UI_fix_2.PNG.



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

[jira] [Created] (CLOUDSTACK-7491) [Automtation] Test case test_02_deploy_ha_vm_from_iso failed, hypervisor parameter password

2014-09-04 Thread Rayees Namathponnan (JIRA) 
Rayees Namathponnan created CLOUDSTACK-7491:
---

 Summary: [Automtation] Test case test_02_deploy_ha_vm_from_iso  
failed, hypervisor parameter password 
 Key: CLOUDSTACK-7491
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7491
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.5.0
 Environment: KVM
Reporter: Rayees Namathponnan
 Fix For: 4.5.0


Test cases failed with below error 

Execute cmd: deployvirtualmachine failed, due to: errorCode: 431, 
errorText:hypervisor parameter is needed to deploy VM or the hypervisor 
parameter value passed is invalid
  begin captured stdout  -
=== TestName: test_02_deploy_ha_vm_from_iso | Status : EXCEPTION ===


-  end captured stdout  --
  begin captured logging  



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

[jira] [Commented] (CLOUDSTACK-7448) [Automation] test_delete_account and test_releaseIP failing in advanced zone

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

CLOUDSTACK-7448 Fix test_delete_account and test_releaseIP

CLOUDSTACK-4840 changed test_data.py to make the lbrule publicport be 22,
instead of . In doing so, this caused the following tests to fail, as they
hit a problem where they tried to use port 22 for both the lbrule and for other
purposes:
integration.smoke.test_network.TestDeleteAccount.test_delete_account
integration.smoke.test_network.TestReleaseIP.test_releaseIP

The reason the change appears to have been made was that in
test_lb_secondary_ip.py, despite setting up the load balancer using lbrule, the
tests then used the SSH port from natrule to try and access the VM. By changing
lbrule to use port 22 (the same as natrule) this avoided the problem.

This patch updates test_lb_secondary_ip.py to use the SSH port in lbrule where
necessary to access the VMs, and reverts the change to test_data.py


 [Automation] test_delete_account and test_releaseIP failing in advanced zone
 

 Key: CLOUDSTACK-7448
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7448
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Alex Brett
 Fix For: 4.5.0


 Advanced zone BVTs are currently seeing two test failures:
 integration.smoke.test_network.TestDeleteAccount.test_delete_account
 integration.smoke.test_network.TestReleaseIP.test_releaseIP
 In both cases the failure is:
 {noformat}
 Execute cmd: createloadbalancerrule failed, due to: errorCode: 537, 
 errorText:The range specified, 22-22, conflicts with rule 55 which has 22-22
 {noformat}
 This appears to be due to this commit from CLOUDSTACK-4840, which changed 
 test_data.py to specify the publicport for the lbrule as 22 and not : 
 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=134a868



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

[jira] [Commented] (CLOUDSTACK-4840) Automation: multiple IPs per NIC

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

CLOUDSTACK-7448 Fix test_delete_account and test_releaseIP

CLOUDSTACK-4840 changed test_data.py to make the lbrule publicport be 22,
instead of . In doing so, this caused the following tests to fail, as they
hit a problem where they tried to use port 22 for both the lbrule and for other
purposes:
integration.smoke.test_network.TestDeleteAccount.test_delete_account
integration.smoke.test_network.TestReleaseIP.test_releaseIP

The reason the change appears to have been made was that in
test_lb_secondary_ip.py, despite setting up the load balancer using lbrule, the
tests then used the SSH port from natrule to try and access the VM. By changing
lbrule to use port 22 (the same as natrule) this avoided the problem.

This patch updates test_lb_secondary_ip.py to use the SSH port in lbrule where
necessary to access the VMs, and reverts the change to test_data.py


 Automation: multiple IPs per NIC 
 -

 Key: CLOUDSTACK-4840
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4840
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
Reporter: Sudha Ponnaganti
Assignee: Ashutosk Kelkar
 Fix For: 4.3.0






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

[jira] [Updated] (CLOUDSTACK-7492) [Automation] - Automate ACL test cases relating to listVolume()

2014-09-04 Thread Sangeetha Hariharan (JIRA) 

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

Sangeetha Hariharan updated CLOUDSTACK-7492:

Description: [Automation] - Automate ACL test cases relating to 
listVolumes()  (was: [Automation] - Automate ACL test cases relating to 
listVirtualMachines())

 [Automation] - Automate ACL test cases relating to listVolume()
 ---

 Key: CLOUDSTACK-7492
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7492
 Project: CloudStack
  Issue Type: Task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: marvin
Affects Versions: 4.4.0
Reporter: Sangeetha Hariharan

 [Automation] - Automate ACL test cases relating to listVolumes()



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

[jira] [Created] (CLOUDSTACK-7492) [Automation] - Automate ACL test cases relating to listVolume()

2014-09-04 Thread Sangeetha Hariharan (JIRA) 
Sangeetha Hariharan created CLOUDSTACK-7492:
---

 Summary: [Automation] - Automate ACL test cases relating to 
listVolume()
 Key: CLOUDSTACK-7492
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7492
 Project: CloudStack
  Issue Type: Task
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: marvin
Affects Versions: 4.4.0
Reporter: Sangeetha Hariharan


[Automation] - Automate ACL test cases relating to listVirtualMachines()



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

[jira] [Updated] (CLOUDSTACK-7492) [Automation] - Automate ACL test cases relating to listVolumes()

2014-09-04 Thread Sangeetha Hariharan (JIRA) 

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

Sangeetha Hariharan updated CLOUDSTACK-7492:

Summary: [Automation] - Automate ACL test cases relating to listVolumes()  
(was: [Automation] - Automate ACL test cases relating to listVolume())

 [Automation] - Automate ACL test cases relating to listVolumes()
 

 Key: CLOUDSTACK-7492
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7492
 Project: CloudStack
  Issue Type: Task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: marvin
Affects Versions: 4.4.0
Reporter: Sangeetha Hariharan

 [Automation] - Automate ACL test cases relating to listVolumes()



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

[jira] [Commented] (CLOUDSTACK-7492) [Automation] - Automate ACL test cases relating to listVolumes()

2014-09-04 Thread ASF subversion and git services (JIRA) 

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

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

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

CLOUDSTACK-7492 -[Automation]-Automate ACL test cases relating to listVloumes()


 [Automation] - Automate ACL test cases relating to listVolumes()
 

 Key: CLOUDSTACK-7492
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7492
 Project: CloudStack
  Issue Type: Task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: marvin
Affects Versions: 4.4.0
Reporter: Sangeetha Hariharan

 [Automation] - Automate ACL test cases relating to listVolumes()



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

[jira] [Updated] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report

2014-09-04 Thread Chandan Purushothama (JIRA) 

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

Chandan Purushothama updated CLOUDSTACK-7493:
-
Component/s: (was: Management Server)
 Test
 Automation

 [Automation] Egress Firewall Rule fails to create on the Virtual Router in 
 Hyper-V Setup - Reports Success instead of failure report
 

 Key: CLOUDSTACK-7493
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


 ==
 Error in management Server log:
 ==
 {code}
 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===  
 10.220.135.217 -- GET  
 jobid=561bbb6c-7931-493d-a778-525086befb96apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3gcommand=queryAsyncJobResultresponse=jsonsignature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq 
 1-4477422454536405316: Sending  { Cmd , MgmtId: 174253150778429, via: 
 1(10.220.163.36), Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
  }
 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq 
 1-4477422454536405316: Executing:  { Cmd , MgmtId: 174253150778429, via: 
 1(10.220.163.36), Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
  }
 2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP : 
 10.220.165.184
 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script: 
 firewall_egress.sh with args:  -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
 2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604:  { Cmd , 
 MgmtId: -1, via: 3, Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
   \connections\: []\n},wait:0}}] }
 2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604:  { Ans: , 
 MgmtId: 174253150778429, via: 3, Ver: v1, Flags: 100010, 
 [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
 2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector 
 found 0 templates to clean up in storage pool: 
 XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
 2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
 found 0 templates to cleanup on template_store_ref for store: 
 cifs://10.220.163.36/storage/secondary
 2014-09-03 18:04:37,831 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
 found 0 snapshots to cleanup on snapshot_store_ref for store: 
 cifs://10.220.163.36/storage/secondary
 2014-09-03 18:04:37,832 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
 found 0 volumes to cleanup on volume_store_ref for store: 
 cifs://10.220.163.36/storage/secondary
 2014-09-03 18:04:37,940 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-316:ctx-c363d57a) firewall_egress.sh execution result: true
 2014-09-03 18:04:37,940 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Response

[jira] [Created] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report

2014-09-04 Thread Chandan Purushothama (JIRA) 
Chandan Purushothama created CLOUDSTACK-7493:


 Summary: [Automation] Egress Firewall Rule fails to create on the 
Virtual Router in Hyper-V Setup - Reports Success instead of failure report
 Key: CLOUDSTACK-7493
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


==
Error in management Server log:
==

{code}
2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet] (catalina-exec-22:ctx-a84568da 
ctx-c6c0fc58 ctx-985e7722) ===END===  10.220.135.217 -- GET  
jobid=561bbb6c-7931-493d-a778-525086befb96apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3gcommand=queryAsyncJobResultresponse=jsonsignature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request] 
(API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq 
1-4477422454536405316: Sending  { Cmd , MgmtId: 174253150778429, via: 
1(10.220.163.36), Ver: v1, Flags: 11, 
[{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
 }
2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request] 
(API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq 
1-4477422454536405316: Executing:  { Cmd , MgmtId: 174253150778429, via: 
1(10.220.163.36), Ver: v1, Flags: 11, 
[{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
 }
2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
(DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP : 
10.220.165.184
2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
(DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script: 
firewall_egress.sh with args:  -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604:  { Cmd , 
MgmtId: -1, via: 3, Ver: v1, Flags: 11, 
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
  \connections\: []\n},wait:0}}] }
2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604:  { Ans: , MgmtId: 
174253150778429, via: 3, Ver: v1, Flags: 100010, 
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl] 
(StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector found 
0 templates to clean up in storage pool: 
XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl] 
(StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
found 0 templates to cleanup on template_store_ref for store: 
cifs://10.220.163.36/storage/secondary
2014-09-03 18:04:37,831 DEBUG [c.c.s.StorageManagerImpl] 
(StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
found 0 snapshots to cleanup on snapshot_store_ref for store: 
cifs://10.220.163.36/storage/secondary
2014-09-03 18:04:37,832 DEBUG [c.c.s.StorageManagerImpl] 
(StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
found 0 volumes to cleanup on volume_store_ref for store: 
cifs://10.220.163.36/storage/secondary
2014-09-03 18:04:37,940 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
(DirectAgent-316:ctx-c363d57a) firewall_egress.sh execution result: true
2014-09-03 18:04:37,940 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Response Received: 
2014-09-03 18:04:37,940 DEBUG [c.c.a.t.Request] (DirectAgent-316:ctx-c363d57a) 
Seq 1-4477422454536405316: Processing:  { Ans: , MgmtId: 174253150778429, via: 
1, Ver: v1, Flags: 0, 
[{com.cloud.agent.api.Answer:{result:true,details:iptables v1.4.14: 
Couldn't load target `_FW_EGRESS_RULES':No such file or directory\n\nTry 
`iptables -h' or 'iptables --help' for more

[jira] [Created] (CLOUDSTACK-7494) [Automation][HyperV] Unable to Migrate VM - Error Message mentions that the operation is not supported

2014-09-04 Thread Chandan Purushothama (JIRA) 
Chandan Purushothama created CLOUDSTACK-7494:


 Summary: [Automation][HyperV] Unable to Migrate VM - Error Message 
mentions that the operation is not supported
 Key: CLOUDSTACK-7494
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7494
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


==
*Error message reported in the management log:*
==

{code}
2014-09-03 17:52:56,853 ERROR [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-64:ctx-b2276c7f job-223/job-224 ctx-43ef9330) Invocation 
exception, caused by: com.cloud.utils.exception.CloudRuntimeException: Unable 
to migrate due to com.cloud.agent.api.MigrateCommand failed due to Failed 
migrating VM i-15-35-VM (GUID AA19CC47-04E5-498F-BC20-574262279F68) due to 
NotSupported
2014-09-03 17:52:56,853 INFO  [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-64:ctx-b2276c7f job-223/job-224 ctx-43ef9330) Rethrow 
exception com.cloud.utils.exception.CloudRuntimeException: Unable to migrate 
due to com.cloud.agent.api.MigrateCommand failed due to Failed migrating VM 
i-15-35-VM (GUID AA19CC47-04E5-498F-BC20-574262279F68) due to NotSupported
2014-09-03 17:52:56,853 DEBUG [c.c.v.VmWorkJobDispatcher] 
(Work-Job-Executor-64:ctx-b2276c7f job-223/job-224) Done with run of VM work 
job: com.cloud.vm.VmWorkMigrate for VM 35, job origin: 223
2014-09-03 17:52:56,853 ERROR [c.c.v.VmWorkJobDispatcher] 
(Work-Job-Executor-64:ctx-b2276c7f job-223/job-224) Unable to complete 
AsyncJobVO {id:224, userId: 2, accountId: 2, instanceType: null, instanceId: 
null, cmd: com.cloud.vm.VmWorkMigrate, cmdInfo: 
rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAI3QAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAnNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXEAfgAJcQB-AAlwcQB-AAk,
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 174253150778429, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: Wed Sep 03 17:52:51 UTC 2014}, job origin:223
com.cloud.utils.exception.CloudRuntimeException: Unable to migrate due to 
com.cloud.agent.api.MigrateCommand failed due to Failed migrating VM i-15-35-VM 
(GUID AA19CC47-04E5-498F-BC20-574262279F68) due to NotSupported
at 
com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1899)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:1799)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:4606)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at 
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4738)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at

  1   2   >