[jira] [Commented] (CLOUDSTACK-4551) Migrating the data volume from NFS to local storage ,underlying disk offering is not changed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797647#comment-13797647 ] Koushik Das commented on CLOUDSTACK-4551: - This shouldn't be allowed. Even though the volume may get migrated from shared to local storage, it is not possible to update the disk offering. So the fix is to disallow migration. Migrating the data volume from NFS to local storage ,underlying disk offering is not changed. - Key: CLOUDSTACK-4551 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4551 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: manasaveloori Assignee: Koushik Das Priority: Critical Fix For: 4.2.1 .Steps: 1.Have CS with 4.2 build. 2.Have 2 primary storages NFS and local,NFS secondary. 3.Create disk offering using local storage. 4.Create a data volume using NFS. 5.Now migrate the volume to local primary storage. Observation: Volume is getting migrated ad storage is changed from NFS to local but the underlying disk offering is not changed. Disk offering with which NFS volume is created id: 3 domain_id: NULL name: Small uuid: d5b03402-9136-476f-9333-7db89def7b12 display_text: Small Disk, 5 GB disk_size: 5368709120 type: Disk tags: NULL recreatable: 0 use_local_storage: 0 unique_name: Cloud.Com-Small system_use: 0 customized: 0 removed: NULL created: 2013-08-29 11:23:41 sort_key: 0 display_offering: 1 customized_iops: NULL min_iops: NULL max_iops: NULL bytes_read_rate: NULL bytes_write_rate: NULL iops_read_rate: NULL iops_write_rate: NULL volume created using NFS mysql select * from volumes where name = sharedBU\G; *** 1. row *** id: 7 account_id: 2 domain_id: 1 pool_id: 201 last_pool_id: NULL instance_id: NULL device_id: NULL name: sharedBU uuid: 945073f2-1680-4e22-af35-9d7c0bb12486 size: 5368709120 folder: /export/home/manasa/primaryVMw path: d52a77ff39c54c499441661ca0af789a pod_id: 1 data_center_id: 1 iscsi_name: NULL host_ip: NULL volume_type: DATADISK pool_type: NetworkFilesystem disk_offering_id: 3 template_id: NULL iso_id: NULL first_snapshot_backup_uuid: NULL recreatable: 0 created: 2013-08-29 12:02:08 attached: NULL updated: 2013-08-29 13:59:42 removed: NULL state: Ready chain_info: NULL update_count: 2 disk_type: NULL vm_snapshot_chain_size: NULL display_volume: 1 format: OVA min_iops: NULL max_iops: NULL 1 row in set (0.00 sec) Volume after migrating to local primary storage. id: 20 account_id: 2 domain_id: 1 pool_id: 200 last_pool_id: 201 instance_id: NULL device_id: NULL name: sharedBU uuid: 0074a14a-ee89-425a-a745-cef7bef6425b size: 5368709120 folder: datastore-14964 path: 9389f319093c4ef9907e16538fe21779 pod_id: 1 data_center_id: 1 iscsi_name: NULL host_ip: NULL volume_type: DATADISK pool_type: NULL disk_offering_id: 3 template_id: NULL iso_id: 0 first_snapshot_backup_uuid: NULL recreatable: 0 created: 2013-08-29 14:34:09 attached: NULL updated: 2013-08-29 14:38:46 removed: NULL state: Ready chain_info: NULL update_count: 2 disk_type: NULL vm_snapshot_chain_size: NULL display_volume: 0 format: OVA
[jira] [Assigned] (CLOUDSTACK-4833) [Automation][BVT] Template and ISO test cases failing from BVT suite, during LIST api call
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye reassigned CLOUDSTACK-4833: -- Assignee: Gaurav Aradhye [Automation][BVT] Template and ISO test cases failing from BVT suite, during LIST api call --- Key: CLOUDSTACK-4833 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4833 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: KVM automation on master Reporter: Rayees Namathponnan Assignee: Gaurav Aradhye Priority: Blocker Fix For: 4.3.0 ISO and Template test cases from master BVT suite i) test_iso.py 2) integration.smoke.test_templates.TestTemplates.test_03_delete_template Both the test cases are failed during list API call, you can see the result at http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/suite=test_templates/lastCompletedBuild/testReport/integration.smoke.test_templates/TestTemplates/test_03_delete_template/ Error Message Execute cmd: listtemplates failed, due to: errorCode: 431, errorText:Unable to execute API command listtemplates due to invalid value. Invalid parameter id value=f3abe3e3-2712-476d-9d71-05207597e4f4 due to incorrect long value format, or entity does not exist or due to incorrect parameter annotation for the field in api cmd class. begin captured logging test_03_delete_template (integration.smoke.test_templates.TestTemplates): DEBUG: Deleting Template ID: f3abe3e3-2712-476d-9d71-05207597e4f4 - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/test/integration/smoke/test_templates.py, line 543, in test_03_delete_template domainid=self.account.domainid File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/integration/lib/common.py, line 534, in list_templates return(apiclient.listTemplates(cmd)) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py, line 713, in listTemplates response = self.connection.marvin_request(command, response_type=response, method=method) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 222, in marvin_request response = jsonHelper.getResultObj(response.json(), response_type) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/jsonHelper.py, line 148, in getResultObj raise cloudstackException.cloudstackAPIException(respname, errMsg) Execute cmd: listtemplates failed, due to: errorCode: 431, errorText:Unable to execute API command listtemplates due to invalid value. Invalid parameter id value=f3abe3e3-2712-476d-9d71-05207597e4f4 due to incorrect long value format, or entity does not exist or due to incorrect parameter annotation for the field in api cmd class. begin captured logging test_03_delete_template (integration.smoke.test_templates.TestTemplates): DEBUG: Deleting Template ID: f3abe3e3-2712-476d-9d71-05207597e4f4 - end captured logging - and http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/suite=test_iso/lastCompletedBuild/testReport/%3Cnose/suite/ContextSuite_context_TestISO__setup/ Error Message Exception while downloading ISO b2a39aff-95c9-447a-9318-a2702eaab1cc: Execute cmd: listisos failed, due to: errorCode: 431, errorText:Unable to execute API command listisos due to invalid value. Invalid parameter id value=b2a39aff-95c9-447a-9318-a2702eaab1cc due to incorrect long value format, or entity does not exist or due to incorrect parameter annotation for the field in api cmd class. Stacktrace Traceback (most recent call last): File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_iso/887/lib/python2.7/site-packages/nose/suite.py, line 208, in run self.setUp() File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_iso/887/lib/python2.7/site-packages/nose/suite.py, line 291, in setUp self.setupContext(ancestor) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_iso/887/lib/python2.7/site-packages/nose/suite.py, line 314, in setupContext
[jira] [Resolved] (CLOUDSTACK-4551) Migrating the data volume from NFS to local storage ,underlying disk offering is not changed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das resolved CLOUDSTACK-4551. - Resolution: Fixed Migrating the data volume from NFS to local storage ,underlying disk offering is not changed. - Key: CLOUDSTACK-4551 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4551 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: manasaveloori Assignee: Koushik Das Priority: Critical Fix For: 4.2.1 .Steps: 1.Have CS with 4.2 build. 2.Have 2 primary storages NFS and local,NFS secondary. 3.Create disk offering using local storage. 4.Create a data volume using NFS. 5.Now migrate the volume to local primary storage. Observation: Volume is getting migrated ad storage is changed from NFS to local but the underlying disk offering is not changed. Disk offering with which NFS volume is created id: 3 domain_id: NULL name: Small uuid: d5b03402-9136-476f-9333-7db89def7b12 display_text: Small Disk, 5 GB disk_size: 5368709120 type: Disk tags: NULL recreatable: 0 use_local_storage: 0 unique_name: Cloud.Com-Small system_use: 0 customized: 0 removed: NULL created: 2013-08-29 11:23:41 sort_key: 0 display_offering: 1 customized_iops: NULL min_iops: NULL max_iops: NULL bytes_read_rate: NULL bytes_write_rate: NULL iops_read_rate: NULL iops_write_rate: NULL volume created using NFS mysql select * from volumes where name = sharedBU\G; *** 1. row *** id: 7 account_id: 2 domain_id: 1 pool_id: 201 last_pool_id: NULL instance_id: NULL device_id: NULL name: sharedBU uuid: 945073f2-1680-4e22-af35-9d7c0bb12486 size: 5368709120 folder: /export/home/manasa/primaryVMw path: d52a77ff39c54c499441661ca0af789a pod_id: 1 data_center_id: 1 iscsi_name: NULL host_ip: NULL volume_type: DATADISK pool_type: NetworkFilesystem disk_offering_id: 3 template_id: NULL iso_id: NULL first_snapshot_backup_uuid: NULL recreatable: 0 created: 2013-08-29 12:02:08 attached: NULL updated: 2013-08-29 13:59:42 removed: NULL state: Ready chain_info: NULL update_count: 2 disk_type: NULL vm_snapshot_chain_size: NULL display_volume: 1 format: OVA min_iops: NULL max_iops: NULL 1 row in set (0.00 sec) Volume after migrating to local primary storage. id: 20 account_id: 2 domain_id: 1 pool_id: 200 last_pool_id: 201 instance_id: NULL device_id: NULL name: sharedBU uuid: 0074a14a-ee89-425a-a745-cef7bef6425b size: 5368709120 folder: datastore-14964 path: 9389f319093c4ef9907e16538fe21779 pod_id: 1 data_center_id: 1 iscsi_name: NULL host_ip: NULL volume_type: DATADISK pool_type: NULL disk_offering_id: 3 template_id: NULL iso_id: 0 first_snapshot_backup_uuid: NULL recreatable: 0 created: 2013-08-29 14:34:09 attached: NULL updated: 2013-08-29 14:38:46 removed: NULL state: Ready chain_info: NULL update_count: 2 disk_type: NULL vm_snapshot_chain_size: NULL display_volume: 0 format: OVA min_iops: NULL max_iops: NULL 2 rows in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4551) Migrating the data volume from NFS to local storage ,underlying disk offering is not changed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797664#comment-13797664 ] ASF subversion and git services commented on CLOUDSTACK-4551: - Commit 7e500a5de87bc11db071d57c90180310a6cb240e in branch refs/heads/4.2 from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7e500a5 ] CLOUDSTACK-4551: Migrating the data volume from NFS to local storage ,underlying disk offering is not changed. Even though the volume may get migrated from shared to local storage, it is not possible to update the disk offering. The fix is to disallow migration from shared to local store. Migrating the data volume from NFS to local storage ,underlying disk offering is not changed. - Key: CLOUDSTACK-4551 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4551 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: manasaveloori Assignee: Koushik Das Priority: Critical Fix For: 4.2.1 .Steps: 1.Have CS with 4.2 build. 2.Have 2 primary storages NFS and local,NFS secondary. 3.Create disk offering using local storage. 4.Create a data volume using NFS. 5.Now migrate the volume to local primary storage. Observation: Volume is getting migrated ad storage is changed from NFS to local but the underlying disk offering is not changed. Disk offering with which NFS volume is created id: 3 domain_id: NULL name: Small uuid: d5b03402-9136-476f-9333-7db89def7b12 display_text: Small Disk, 5 GB disk_size: 5368709120 type: Disk tags: NULL recreatable: 0 use_local_storage: 0 unique_name: Cloud.Com-Small system_use: 0 customized: 0 removed: NULL created: 2013-08-29 11:23:41 sort_key: 0 display_offering: 1 customized_iops: NULL min_iops: NULL max_iops: NULL bytes_read_rate: NULL bytes_write_rate: NULL iops_read_rate: NULL iops_write_rate: NULL volume created using NFS mysql select * from volumes where name = sharedBU\G; *** 1. row *** id: 7 account_id: 2 domain_id: 1 pool_id: 201 last_pool_id: NULL instance_id: NULL device_id: NULL name: sharedBU uuid: 945073f2-1680-4e22-af35-9d7c0bb12486 size: 5368709120 folder: /export/home/manasa/primaryVMw path: d52a77ff39c54c499441661ca0af789a pod_id: 1 data_center_id: 1 iscsi_name: NULL host_ip: NULL volume_type: DATADISK pool_type: NetworkFilesystem disk_offering_id: 3 template_id: NULL iso_id: NULL first_snapshot_backup_uuid: NULL recreatable: 0 created: 2013-08-29 12:02:08 attached: NULL updated: 2013-08-29 13:59:42 removed: NULL state: Ready chain_info: NULL update_count: 2 disk_type: NULL vm_snapshot_chain_size: NULL display_volume: 1 format: OVA min_iops: NULL max_iops: NULL 1 row in set (0.00 sec) Volume after migrating to local primary storage. id: 20 account_id: 2 domain_id: 1 pool_id: 200 last_pool_id: 201 instance_id: NULL device_id: NULL name: sharedBU uuid: 0074a14a-ee89-425a-a745-cef7bef6425b size: 5368709120 folder: datastore-14964 path: 9389f319093c4ef9907e16538fe21779 pod_id: 1 data_center_id: 1 iscsi_name: NULL host_ip: NULL volume_type: DATADISK pool_type: NULL disk_offering_id: 3 template_id: NULL iso_id: 0 first_snapshot_backup_uuid: NULL recreatable: 0 created: 2013-08-29 14:34:09 attached: NULL
[jira] [Commented] (CLOUDSTACK-4624) VM Migration fails in 'Security Group Enabled Advanced Zone' with CloudRuntimeException: callHostPlugin failed for cmd: network_rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797695#comment-13797695
]
Paul Angus commented on CLOUDSTACK-4624:
Hi Jayapal
/var/log/SMLog below...
Oct 17 08:41:02 hdkvm02c SM: [9226] lock: acquired
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/sr
Oct 17 08:41:02 hdkvm02c SM: [9226] sr_scan {'sr_uuid':
'5609c1c0-03e4-8b58-1bf1-533f1ade34a1', 'subtask_of':
'DummyRef:|84d09d98-57d4-2c63-b97c-cf1da9c5f87a|SR.scan', 'args': [],
'host_ref': 'OpaqueRef:99e28465-5100-6b59-e9d7-ea48b5cdde49', 'session_ref':
'OpaqueRef:75f0e554-b926-847e-5730-ccd7591c08b1', 'device_config': {'device':
'/dev/md0', 'SRmaster': 'true'}, 'command': 'sr_scan', 'sr_ref':
'OpaqueRef:3155b7a0-1a0a-6dea-42d3-db95d84dbd82'}
Oct 17 08:41:02 hdkvm02c SM: [9226] ['/usr/bin/vhd-util', 'scan', '-f', '-c',
'-m', '/var/run/sr-mount/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/*.vhd']
Oct 17 08:41:02 hdkvm02c SM: [9226] pread SUCCESS
Oct 17 08:41:02 hdkvm02c SM: [9226] ['ls',
'/var/run/sr-mount/5609c1c0-03e4-8b58-1bf1-533f1ade34a1', '-1', '--color=never']
Oct 17 08:41:02 hdkvm02c SM: [9226] pread SUCCESS
Oct 17 08:41:02 hdkvm02c SM: [9226] lock: tried lock
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/running, acquired: True
(exists: True)
Oct 17 08:41:02 hdkvm02c SM: [9226] lock: released
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/running
Oct 17 08:41:02 hdkvm02c SM: [9226] Kicking GC
Oct 17 08:41:02 hdkvm02c SMGC: [9226] === SR
5609c1c0-03e4-8b58-1bf1-533f1ade34a1: gc ===
Oct 17 08:41:02 hdkvm02c SMGC: [9230] Will finish as PID [9231]
Oct 17 08:41:02 hdkvm02c SMGC: [9226] New PID [9230]
Oct 17 08:41:02 hdkvm02c SM: [9226] lock: closed
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/running
Oct 17 08:41:02 hdkvm02c SM: [9226] lock: released
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/sr
Oct 17 08:41:02 hdkvm02c SM: [9226] lock: closed
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/sr
Oct 17 08:41:03 hdkvm02c SMGC: [9231] Found 0 cache files
Oct 17 08:41:03 hdkvm02c SM: [9231] lock: tried lock
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/sr, acquired: True (exists:
True)
Oct 17 08:41:03 hdkvm02c SM: [9231] ['/usr/bin/vhd-util', 'scan', '-f', '-c',
'-m', '/var/run/sr-mount/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/*.vhd']
Oct 17 08:41:03 hdkvm02c SM: [9231] pread SUCCESS
Oct 17 08:41:03 hdkvm02c SMGC: [9231] SR 5609
('5609c1c0-03e4-8b58-1bf1-533f1ade34a1') (0 VDIs in 0 VHD trees): no changes
Oct 17 08:41:03 hdkvm02c SM: [9231] lock: released
/var/lock/sm/5609c1c0-03e4-8b58-1bf1-533f1ade34a1/sr
Oct 17 08:41:03 hdkvm02c SMGC: [9231] No work, exiting
Oct 17 08:41:03 hdkvm02c SMGC: [9231] In cleanup
Oct 17 08:41:03 hdkvm02c SMGC: [9231] SR 5609
('5609c1c0-03e4-8b58-1bf1-533f1ade34a1') (0 VDIs in 0 VHD trees): no changes
Oct 17 08:41:08 hdkvm02c SM: [9365] VMOPS enter gethostvmstats
Oct 17 08:41:08 hdkvm02c SM: [9365] VMOPS exit gethostvmstats
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS enter get_rule_logs_for_vms
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS enter
network_rules_for_rebooted_vm
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS enter check_domid_changed
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS exit check_domid_changed
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS exit
network_rules_for_rebooted_vm
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS enter
network_rules_for_rebooted_vm
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS enter check_domid_changed
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS exit check_domid_changed
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS exit
network_rules_for_rebooted_vm
Oct 17 08:41:16 hdkvm02c SM: [9486] VMOPS exit get_rule_logs_for_vms
Oct 17 08:41:29 hdkvm02c SM: [11083] lock: acquired
/var/lock/sm/081b1189-0b81-d55c-b230-b914ce8a9030/sr
Oct 17 08:41:29 hdkvm02c SM: [11083] ['/usr/sbin/td-util', 'query', 'vhd',
'-vpf',
'/var/run/sr-mount/081b1189-0b81-d55c-b230-b914ce8a9030/f5e5ffae-0c95-4db8-a3d1-c17c8879f839.vhd']
Oct 17 08:41:29 hdkvm02c SM: [11083] pread SUCCESS
Oct 17 08:41:29 hdkvm02c SM: [11083] vdi_attach {'sr_uuid':
'081b1189-0b81-d55c-b230-b914ce8a9030', 'subtask_of':
'DummyRef:|684284be-93d1-5813-083b-98d6632b3a54|VDI.attach', 'vdi_ref':
'OpaqueRef:524343bd-1a86-ac9a-b9e9-9bba88bb66a3', 'vdi_on_boot': 'persist',
'args': ['true'], 'vdi_location': 'f5e5ffae-0c95-4db8-a3d1-c17c8879f839',
'host_ref': 'OpaqueRef:99e28465-5100-6b59-e9d7-ea48b5cdde49', 'session_ref':
'OpaqueRef:c5a97db8-6732-5bcd-4bad-6cf083d8a6be', 'device_config': {'SRmaster':
'false', 'serverpath': '/vol/test_p2_c1_pri2/RootQtree', 'server':
'10.28.231.2'}, 'command': 'vdi_attach', 'vdi_allow_caching': 'false',
'sr_ref': 'OpaqueRef:e0b08b24-46c2-f945-36b3-f9feadb3aa93', 'vdi_uuid':
'f5e5ffae-0c95-4db8-a3d1-c17c8879f839'}
Oct
[jira] [Commented] (CLOUDSTACK-4833) [Automation][BVT] Template and ISO test cases failing from BVT suite, during LIST api call
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797707#comment-13797707 ] Gaurav Aradhye commented on CLOUDSTACK-4833: Ran ISO and templates test cases, could not reproduce these issues. Test ran ok. Template delete test case log: == result.log == test_01_create_template (test_templates_fixed.TestCreateTemplate) Test create public private template ... == client.log == 2013-10-16 20:24:06,878 - DEBUG - test_03_delete_template (test_templates_fixed.TestTemplates) - Deleting Template ID: d3d6d6ab-24e8-40fe-8b8c-e82dd1337ffa == result.log == skipped 'Skip' test_02_edit_template (test_templates_fixed.TestTemplates) Test Edit template ... skipped 'Skip' test_03_delete_template (test_templates_fixed.TestTemplates) Test delete template ... ok test_04_extract_template (test_templates_fixed.TestTemplates) Test for extract template ... skipped 'Skip' test_05_template_permissions (test_templates_fixed.TestTemplates) Update Test for template permissions ... skipped 'Skip' test_06_copy_template (test_templates_fixed.TestTemplates) Test for copy template from one zone to another ... skipped 'Skip' test_07_list_public_templates (test_templates_fixed.TestTemplates) Test only public templates are visible to normal user ... skipped 'Skip' test_08_list_system_templates (test_templates_fixed.TestTemplates) Test System templates are not visible to normal user ... skipped 'Skip' -- Ran 8 tests in 495.756s OK (skipped=7) ISO log: test_01_create_iso (test_iso.TestCreateIso) Test create public private ISO ... ok test_02_edit_iso (test_iso.TestISO) Test Edit ISO ... ok test_03_delete_iso (test_iso.TestISO) Test delete ISO ... ok test_04_extract_Iso (test_iso.TestISO) Test for extract ISO ... ok test_05_iso_permissions (test_iso.TestISO) Update Test for ISO permissions ... ok test_06_copy_iso (test_iso.TestISO) Test for copy ISO from one zone to another ... ok -- Ran 6 tests in 341.819s OK [Automation][BVT] Template and ISO test cases failing from BVT suite, during LIST api call --- Key: CLOUDSTACK-4833 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4833 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: KVM automation on master Reporter: Rayees Namathponnan Assignee: Gaurav Aradhye Priority: Blocker Fix For: 4.3.0 ISO and Template test cases from master BVT suite i) test_iso.py 2) integration.smoke.test_templates.TestTemplates.test_03_delete_template Both the test cases are failed during list API call, you can see the result at http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/suite=test_templates/lastCompletedBuild/testReport/integration.smoke.test_templates/TestTemplates/test_03_delete_template/ Error Message Execute cmd: listtemplates failed, due to: errorCode: 431, errorText:Unable to execute API command listtemplates due to invalid value. Invalid parameter id value=f3abe3e3-2712-476d-9d71-05207597e4f4 due to incorrect long value format, or entity does not exist or due to incorrect parameter annotation for the field in api cmd class. begin captured logging test_03_delete_template (integration.smoke.test_templates.TestTemplates): DEBUG: Deleting Template ID: f3abe3e3-2712-476d-9d71-05207597e4f4 - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/test/integration/smoke/test_templates.py, line 543, in test_03_delete_template domainid=self.account.domainid File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/integration/lib/common.py, line 534, in list_templates return(apiclient.listTemplates(cmd)) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py, line 713, in listTemplates response = self.connection.marvin_request(command, response_type=response, method=method) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 222, in marvin_request response = jsonHelper.getResultObj(response.json(), response_type) File
[jira] [Commented] (CLOUDSTACK-4835) [Automation] [BVT] Update global configuration test cases failed in master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797717#comment-13797717 ] Gaurav Aradhye commented on CLOUDSTACK-4835: Could not reproduce. Log: == client.log == 2013-10-16 21:56:36,048 - DEBUG - test_UpdateConfigParamWithScope (test_global_settings.TestUpdateConfigWithScope) - updated the parameter use.external.dns with value true == result.log == test_UpdateConfigParamWithScope (test_global_settings.TestUpdateConfigWithScope) ... ok -- Ran 1 test in 2.720s OK [Automation] [BVT] Update global configuration test cases failed in master -- Key: CLOUDSTACK-4835 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4835 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: KVM Branch - master Reporter: Rayees Namathponnan Assignee: Gaurav Aradhye Priority: Blocker Fix For: 4.3.0 Below BVT test cases failed, integration.smoke.test_global_settings.TestUpdateConfigWithScope.test_UpdateConfigParamWithScope Unable to find the global property use.external.dns in master, is it removed ? you can see the result at http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/lastCompletedBuild/suite=test_global_settings/#showFailuresLink Error Message Execute cmd: updateconfiguration failed, due to: errorCode: 431, errorText:Config parameter with name use.external.dns doesn't exist Stacktrace Traceback (most recent call last): File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/test/integration/smoke/test_global_settings.py, line 47, in test_UpdateConfigParamWithScope updateConfigurationResponse = self.apiClient.updateConfiguration(updateConfigurationCmd) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py, line 1188, in updateConfiguration response = self.connection.marvin_request(command, response_type=response, method=method) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 222, in marvin_request response = jsonHelper.getResultObj(response.json(), response_type) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/jsonHelper.py, line 148, in getResultObj raise cloudstackException.cloudstackAPIException(respname, errMsg) cloudstackAPIException: Execute cmd: updateconfiguration failed, due to: errorCode: 431, errorText:Config parameter with name use.external.dns doesn't exist -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4835) [Automation] [BVT] Update global configuration test cases failed in master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye reassigned CLOUDSTACK-4835: -- Assignee: Gaurav Aradhye [Automation] [BVT] Update global configuration test cases failed in master -- Key: CLOUDSTACK-4835 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4835 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: KVM Branch - master Reporter: Rayees Namathponnan Assignee: Gaurav Aradhye Priority: Blocker Fix For: 4.3.0 Below BVT test cases failed, integration.smoke.test_global_settings.TestUpdateConfigWithScope.test_UpdateConfigParamWithScope Unable to find the global property use.external.dns in master, is it removed ? you can see the result at http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/lastCompletedBuild/suite=test_global_settings/#showFailuresLink Error Message Execute cmd: updateconfiguration failed, due to: errorCode: 431, errorText:Config parameter with name use.external.dns doesn't exist Stacktrace Traceback (most recent call last): File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/test/integration/smoke/test_global_settings.py, line 47, in test_UpdateConfigParamWithScope updateConfigurationResponse = self.apiClient.updateConfiguration(updateConfigurationCmd) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py, line 1188, in updateConfiguration response = self.connection.marvin_request(command, response_type=response, method=method) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 222, in marvin_request response = jsonHelper.getResultObj(response.json(), response_type) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/jsonHelper.py, line 148, in getResultObj raise cloudstackException.cloudstackAPIException(respname, errMsg) cloudstackAPIException: Execute cmd: updateconfiguration failed, due to: errorCode: 431, errorText:Config parameter with name use.external.dns doesn't exist -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4834) [Automation] Failed to create volume; failed with error Invalid parameter diskofferingid value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye reassigned CLOUDSTACK-4834: -- Assignee: Gaurav Aradhye [Automation] Failed to create volume; failed with error Invalid parameter diskofferingid value Key: CLOUDSTACK-4834 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4834 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.3.0 Environment: KVM Branch Master Reporter: Rayees Namathponnan Assignee: Gaurav Aradhye Priority: Blocker Fix For: 4.3.0 Attachments: CLOUDSTACK-4834.rar Volume test cases from BVT suite failed, test cases failed while adding new volume; i tried to new volume from UI, its failed with error Unable to execute API command createvolume due to invalid value. Invalid parameter diskofferingid value=7c5f301b-69b3-43f4-a5b8-8acb356c5e3f due to incorrect long value format, or entity does not exist or due to incorrect parameter annotation for the field in api cmd class Test case creating with API, observed below error in log Execute cmd: createvolume failed, due to: errorCode: 431, errorText:volume size 1073741824, but the maximum size allowed is 0 Gb Log from MS log 2013-10-07 12:34:58,564 DEBUG [c.c.a.ApiServlet] (catalina-exec-5:ctx-6b44eb58) ===START=== 10.223.240.194 -- GET account=test-resource_details-TestResourceDetail-IMWBHVdomainid=34f66d20-2f83-11e3-a447-1a6f7bb0d0a8name=ndmzoneid=79 ed0a9e-469c-460d-b674-0a2944e5d557apiKey=ylSEBq6mjjv1nOqm2lsFI-uBAbDbeUuX2mOIUslHLFH62Vmgl2E5scxr5lUaJ8lkZ4qJ24Mg7mY6tMgsDv6CTwcommand=createVolumesignature=8ySmF7tiGjJaxpZwKs5iPXLo%2FtU%3Ddiskofferingid=aeeb298c-4d10-4bab-ba13-ad67 f2dc026cresponse=json 2013-10-07 12:34:58,629 INFO [c.c.a.ApiServer] (catalina-exec-5:ctx-6b44eb58 ctx-3e806b15 ctx-60ef7e57) volume size 1073741824, but the maximum size allowed is 0 Gb. 2013-10-07 12:34:58,637 DEBUG [c.c.a.ApiServlet] (catalina-exec-5:ctx-6b44eb58 ctx-3e806b15 ctx-60ef7e57) ===END=== 10.223.240.194 -- GET account=test-resource_details-TestResourceDetail-IMWBHVdomainid=34f66d20-2f83-11e3-a447-1a6f7bb0d0a8name=ndmzoneid=79ed0a9e-469c-460d-b674-0a2944e5d557apiKey=ylSEBq6mjjv1nOqm2lsFI-uBAbDbeUuX2mOIUslHLFH62Vmgl2E5scxr5lUaJ8lkZ4qJ24Mg7mY6tMgsDv6CTwcommand=createVolumesignature=8ySmF7tiGjJaxpZwKs5iPXLo%2FtU%3Ddiskofferingid=aeeb298c-4d10-4bab-ba13-ad67f2dc026cresponse=json Attached MS log with defect -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4834) [Automation] Failed to create volume; failed with error Invalid parameter diskofferingid value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797736#comment-13797736 ] Gaurav Aradhye commented on CLOUDSTACK-4834: Could not reproduce. I also tried adding volume from UI. Operation succeeded. Log: test_01_create_volume (test_volumes.TestCreateVolume) Test Volume creation for all Disk Offerings (incl. custom) ... ok test_02_attach_volume (test_volumes.TestVolumes) Attach a created Volume to a Running VM ... ok test_03_download_attached_volume (test_volumes.TestVolumes) Download a Volume attached to a VM ... ok test_04_delete_attached_volume (test_volumes.TestVolumes) Delete a Volume attached to a VM ... ok test_05_detach_volume (test_volumes.TestVolumes) Detach a Volume attached to a VM ... ok test_06_download_detached_volume (test_volumes.TestVolumes) Download a Volume unattached to an VM ... ok test_07_resize_fail (test_volumes.TestVolumes) Test resize (negative) non-existent volume ... ok test_08_resize_volume (test_volumes.TestVolumes) Test resize a volume ... ok test_09_delete_detached_volume (test_volumes.TestVolumes) Delete a Volume unattached to an VM ... ok -- Ran 9 tests in 1196.089s OK [Automation] Failed to create volume; failed with error Invalid parameter diskofferingid value Key: CLOUDSTACK-4834 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4834 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.3.0 Environment: KVM Branch Master Reporter: Rayees Namathponnan Assignee: Gaurav Aradhye Priority: Blocker Fix For: 4.3.0 Attachments: CLOUDSTACK-4834.rar Volume test cases from BVT suite failed, test cases failed while adding new volume; i tried to new volume from UI, its failed with error Unable to execute API command createvolume due to invalid value. Invalid parameter diskofferingid value=7c5f301b-69b3-43f4-a5b8-8acb356c5e3f due to incorrect long value format, or entity does not exist or due to incorrect parameter annotation for the field in api cmd class Test case creating with API, observed below error in log Execute cmd: createvolume failed, due to: errorCode: 431, errorText:volume size 1073741824, but the maximum size allowed is 0 Gb Log from MS log 2013-10-07 12:34:58,564 DEBUG [c.c.a.ApiServlet] (catalina-exec-5:ctx-6b44eb58) ===START=== 10.223.240.194 -- GET account=test-resource_details-TestResourceDetail-IMWBHVdomainid=34f66d20-2f83-11e3-a447-1a6f7bb0d0a8name=ndmzoneid=79 ed0a9e-469c-460d-b674-0a2944e5d557apiKey=ylSEBq6mjjv1nOqm2lsFI-uBAbDbeUuX2mOIUslHLFH62Vmgl2E5scxr5lUaJ8lkZ4qJ24Mg7mY6tMgsDv6CTwcommand=createVolumesignature=8ySmF7tiGjJaxpZwKs5iPXLo%2FtU%3Ddiskofferingid=aeeb298c-4d10-4bab-ba13-ad67 f2dc026cresponse=json 2013-10-07 12:34:58,629 INFO [c.c.a.ApiServer] (catalina-exec-5:ctx-6b44eb58 ctx-3e806b15 ctx-60ef7e57) volume size 1073741824, but the maximum size allowed is 0 Gb. 2013-10-07 12:34:58,637 DEBUG [c.c.a.ApiServlet] (catalina-exec-5:ctx-6b44eb58 ctx-3e806b15 ctx-60ef7e57) ===END=== 10.223.240.194 -- GET account=test-resource_details-TestResourceDetail-IMWBHVdomainid=34f66d20-2f83-11e3-a447-1a6f7bb0d0a8name=ndmzoneid=79ed0a9e-469c-460d-b674-0a2944e5d557apiKey=ylSEBq6mjjv1nOqm2lsFI-uBAbDbeUuX2mOIUslHLFH62Vmgl2E5scxr5lUaJ8lkZ4qJ24Mg7mY6tMgsDv6CTwcommand=createVolumesignature=8ySmF7tiGjJaxpZwKs5iPXLo%2FtU%3Ddiskofferingid=aeeb298c-4d10-4bab-ba13-ad67f2dc026cresponse=json Attached MS log with defect -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4747) [Automation] Test cases creating account with more 100 character; account creation failing due to this
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797741#comment-13797741 ] ASF subversion and git services commented on CLOUDSTACK-4747: - Commit c5e1c4725c3658cae967c63cbae0ffe598f227ef in branch refs/heads/master from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c5e1c47 ] CLOUDSTACK-4747: Rename testcase name to use lesser characters Renamed testcase name and also initialised _cleanup so that it does not break on non-NS Cloudstack setup. Signed-off-by: venkataswamybabu budumuru venkataswamybabu.budum...@citrix.com [Automation] Test cases creating account with more 100 character; account creation failing due to this Key: CLOUDSTACK-4747 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4747 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin, Test Affects Versions: 4.2.1 Environment: Automation Reporter: Rayees Namathponnan Assignee: Girish Shilamkar Priority: Blocker Fix For: 4.2.1 You cannot create account more than 100 characters; We added test case's name in account; but should trim the account name maximum to 99 characters to avoid these kind of failures integration.component.test_netscaler_nw_off.TestNOWithNetscaler.test_02_network_off_with_conserve_mode_netscaler Execute cmd: createaccount failed, due to: errorCode: 530, errorText:DB Exception on: com.mysql.jdbc.PreparedStatement@4d345362: INSERT INTO account (account.account_name, account.type, account.domain_id, account.state, account.cleanup_needed, account.network_domain, account.uuid, account.default_zone_id, account.default) VALUES (_binary'test-test_netscaler_nw_off-TestNwOffSToDUpgrade-test_02_network_off_with_conserve_mode_netscaler-AZBFBO', 2, 1, 'enabled', 0, null, _binary'0c361f17-c605-456f-ad0b-b1952bce575a', null, 0) Stacktrace Traceback (most recent call last): File /usr/local/lib/python2.7/unittest/case.py, line 311, in run self.setUp() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_netscaler_nw_off.py, line 2428, in setUp domainid=self.domain.id File /usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, line 116, in create account = apiclient.createAccount(cmd) File /usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py, line 495, in createAccount response = self.connection.marvin_request(command, response_type=response, method=method) File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 222, in marvin_request response = jsonHelper.getResultObj(response.json(), response_type) File /usr/local/lib/python2.7/site-packages/marvin/jsonHelper.py, line 148, in getResultObj raise cloudstackException.cloudstackAPIException(respname, errMsg) cloudstackAPIException: Execute cmd: createaccount failed, due to: errorCode: 530, errorText:DB Exception on: com.mysql.jdbc.PreparedStatement@4d345362: INSERT INTO account (account.account_name, account.type, account.domain_id, account.state, account.cleanup_needed, account.network_domain, account.uuid, account.default_zone_id, account.default) VALUES (_binary'test-test_netscaler_nw_off-TestNwOffSToDUpgrade-test_02_network_off_with_conserve_mode_netscaler-AZBFBO', 2, 1, 'enabled', 0, null, _binary'0c361f17-c605-456f-ad0b-b1952bce575a', null, 0) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4682) VMs are getting deployed with shared service offering and local compute offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797743#comment-13797743 ] ASF subversion and git services commented on CLOUDSTACK-4682: - Commit e58bef22c161a939b52b7748c17238476bac923b in branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e58bef2 ] CLOUDSTACK-4682: VMs are getting deployed with shared service offering and local compute offering VM deployment is fine, issue is in attach volume where all possible scenarios are not handled. The following needs to be logic of attached volume: 1. if data volume scope is zone then allow attach (this is already there) 2. if data volume scope is cluster a. if root volume scope is host, allow if both are in same cluster (already there) b. if root volume scope is zone, allow if vm and data volume in same cluster (fixed as part of this commit) 3. if data volume scope is host allow if vm and data volume in same host (fixed as part of this commit) VMs are getting deployed with shared service offering and local compute offering -- Key: CLOUDSTACK-4682 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4682 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0, 4.2.1 Environment: hyp:KVM Reporter: prashant kumar mishra Assignee: Koushik Das Priority: Critical Fix For: 4.2.1 Attachments: Logs_DB.rar Steps to reproduce --- 1-prepare a CS setup with kvm host+zone wide primary storage 2-mark Local storage enabled to true at zone level and restart MS 3-create a local disk offering 4-deploy a vm with shared service offering and local compute offering expected --- vm deployment should fail because CS can't move volume between scope: HOST and ZONE Actual -- vm deployment went successful with root disk on shared and data disk on local storage storage My observation -- once i detach the data disk(created in step 4) ,was not able to attach data disk to vm(deployed in step 4) with error --- 2013-09-16 13:01:53,697 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-9:job-35 = [ ad075b33-d308-4056-bc8a-f3a7d71ad60f ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd com.cloud.utils.exception.CloudRuntimeException: Can't move volume between scope: HOST and ZONE at com.cloud.storage.VolumeManagerImpl.needMoveVolume(VolumeManagerImpl.java:1605) at com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1880) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:122) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) 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 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2013-09-16 13:01:53,702 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-9:job-35 = [ ad075b33-d308-4056-bc8a-f3a7d71ad60f ]) Complete async job-35 = [ ad075b33-d308-4056-bc8a-f3a7d71ad60f ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Can't move volume between scope: HOST and ZONE -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4747) [Automation] Test cases creating account with more 100 character; account creation failing due to this
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797744#comment-13797744 ] ASF subversion and git services commented on CLOUDSTACK-4747: - Commit 08e69f130f142b0b034b6f42715ae0d1ca390c12 in branch refs/heads/4.2 from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=08e69f1 ] CLOUDSTACK-4747: Rename testcase name to use lesser characters Renamed testcase name and also initialised _cleanup so that it does not break on non-NS Cloudstack setup. Signed-off-by: venkataswamybabu budumuru venkataswamybabu.budum...@citrix.com (cherry picked from commit c5e1c4725c3658cae967c63cbae0ffe598f227ef) [Automation] Test cases creating account with more 100 character; account creation failing due to this Key: CLOUDSTACK-4747 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4747 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin, Test Affects Versions: 4.2.1 Environment: Automation Reporter: Rayees Namathponnan Assignee: Girish Shilamkar Priority: Blocker Fix For: 4.2.1 You cannot create account more than 100 characters; We added test case's name in account; but should trim the account name maximum to 99 characters to avoid these kind of failures integration.component.test_netscaler_nw_off.TestNOWithNetscaler.test_02_network_off_with_conserve_mode_netscaler Execute cmd: createaccount failed, due to: errorCode: 530, errorText:DB Exception on: com.mysql.jdbc.PreparedStatement@4d345362: INSERT INTO account (account.account_name, account.type, account.domain_id, account.state, account.cleanup_needed, account.network_domain, account.uuid, account.default_zone_id, account.default) VALUES (_binary'test-test_netscaler_nw_off-TestNwOffSToDUpgrade-test_02_network_off_with_conserve_mode_netscaler-AZBFBO', 2, 1, 'enabled', 0, null, _binary'0c361f17-c605-456f-ad0b-b1952bce575a', null, 0) Stacktrace Traceback (most recent call last): File /usr/local/lib/python2.7/unittest/case.py, line 311, in run self.setUp() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_netscaler_nw_off.py, line 2428, in setUp domainid=self.domain.id File /usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, line 116, in create account = apiclient.createAccount(cmd) File /usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py, line 495, in createAccount response = self.connection.marvin_request(command, response_type=response, method=method) File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 222, in marvin_request response = jsonHelper.getResultObj(response.json(), response_type) File /usr/local/lib/python2.7/site-packages/marvin/jsonHelper.py, line 148, in getResultObj raise cloudstackException.cloudstackAPIException(respname, errMsg) cloudstackAPIException: Execute cmd: createaccount failed, due to: errorCode: 530, errorText:DB Exception on: com.mysql.jdbc.PreparedStatement@4d345362: INSERT INTO account (account.account_name, account.type, account.domain_id, account.state, account.cleanup_needed, account.network_domain, account.uuid, account.default_zone_id, account.default) VALUES (_binary'test-test_netscaler_nw_off-TestNwOffSToDUpgrade-test_02_network_off_with_conserve_mode_netscaler-AZBFBO', 2, 1, 'enabled', 0, null, _binary'0c361f17-c605-456f-ad0b-b1952bce575a', null, 0) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4624) VM Migration fails in 'Security Group Enabled Advanced Zone' with CloudRuntimeException: callHostPlugin failed for cmd: network_rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797748#comment-13797748
]
Jayapal Reddy commented on CLOUDSTACK-4624:
---
Rules config failed for the VM in below logs.
Oct 17 08:41:36 hdkvm02c SM: [11509] VMOPS enter network_rules
Oct 17 08:41:36 hdkvm02c SM: [11509] ['ifconfig', 'tap13.0']
Oct 17 08:41:36 hdkvm02c SM: [11509] FAILED in util.pread: (rc 1) stdout: '',
stderr: 'tap13.0: error fetching interface information: Device not found
Oct 17 08:41:36 hdkvm02c SM: [11509] '
Oct 17 08:41:36 hdkvm02c SM: [11509] VMOPS enter check_rule_log_for_vm
Oct 17 08:41:36 hdkvm02c SM: [11509] Failed to find logfile
/var/run/cloud/i-2-60-VM.log
Oct 17 08:41:36 hdkvm02c SM: [11509] VMOPS exit check_rule_log_for_vm
Oct 17 08:41:36 hdkvm02c SM: [11509] Change detected in vmId or vmIp or domId,
resetting default rules
Oct 17 08:41:36 hdkvm02c SM: [11509] VMOPS enter default_network_rules
Oct 17 08:41:36 hdkvm02c SM: [11509] Failed to network rule !
Oct 17 08:41:36 hdkvm02c SM: [11509] VMOPS exit network_rules
VM Migration fails in 'Security Group Enabled Advanced Zone' with
CloudRuntimeException: callHostPlugin failed for cmd: network_rules
-
Key: CLOUDSTACK-4624
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4624
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: XenServer
Affects Versions: 4.2.0, Future
Environment: CloudStack 4.2.0 with XenServer 6.1 or 6.2
Reporter: Paul Angus
Assignee: Jayapal Reddy
Priority: Critical
Fix For: 4.2.1
VM Migration fails in a 'Security Group Enabled Advanced Zone' with
CloudRuntimeException: callHostPlugin failed for cmd: network_rules
013-09-06 14:18:07,711 DEBUG [network.security.SecurityGroupManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
Group Mgr v2: scheduling ruleset updates for 1 vms (unique=1), current queue
size=0
2013-09-06 14:18:07,715 DEBUG [network.security.SecurityGroupManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
Group Mgr v2: done scheduling ruleset updates for 1 vms: num new jobs=1 num
rows insert or updated=1 time taken=4
2013-09-06 14:18:07,715 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) VM state
transitted from :Migrating to Running with event: OperationSucceededvm's
original host id: 7 new host id: 8 host id before state transition: 8
2013-09-06 14:18:07,721 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-244:null) Ping from 5
2013-09-06 14:18:07,728 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
actual total CPU: 63840 and CPU after applying overprovisioning: 127680
2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
actual total RAM: 267404820480 and RAM after applying overprovisioning:
267404820480
2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
cpu from host: 7, old used: 1000,reserved: 0, actual total: 63840, total with
overprovisioning: 127680; new used: 0,reserved:0; movedfromreserved:
false,moveToReserveredfalse
2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
mem from host: 7, old used: 1073741824,reserved: 0, total: 267404820480; new
used: 0,reserved:0; movedfromreserved: false,moveToReserveredfalse
2013-09-06 14:18:07,731 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null)
===START=== 10.67.9.233 -- GET
command=queryAsyncJobResultjobId=16e9e8e3-460e-4a72-a455-d65b01f3b360response=jsonsessionkey=hLoqoRm93LQk67lSOtoBQZludFg%3D_=1378473487668
2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
8-576979043: Sending { Cmd , MgmtId: 345052351047, via: 8, Ver: v1, Flags:
100011,
[{com.cloud.agent.api.CheckVirtualMachineCommand:{vmName:i-2-11-VM,wait:20}}]
}
2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
8-576979043: Executing: { Cmd , MgmtId: 345052351047, via: 8, Ver: v1,
Flags: 100011,
[{com.cloud.agent.api.CheckVirtualMachineCommand:{vmName:i-2-11-VM,wait:20}}]
}
[jira] [Updated] (CLOUDSTACK-2413) The dialog box Change Compute Offering for a instance, display the Description (instead of the Name) of compute offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-2413: - Fix Version/s: (was: 4.2.0) 4.2.1 The dialog box Change Compute Offering for a instance, display the Description (instead of the Name) of compute offering Key: CLOUDSTACK-2413 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2413 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.1.0, 4.2.0 Reporter: Milamber Assignee: Milamber Fix For: 4.1.0, 4.2.1 The dialog box Change Compute Offering for a instance, display the Description (instead of the Name) of compute offering. I think would be better to display the Name. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4551) Migrating the data volume from NFS to local storage ,underlying disk offering is not changed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797765#comment-13797765 ] ASF subversion and git services commented on CLOUDSTACK-4551: - Commit 9fc47148983919392f6a238b45fac824c50b in branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9fc471d ] CLOUDSTACK-4551: Migrating the data volume from NFS to local storage ,underlying disk offering is not changed. Even though the volume may get migrated from shared to local storage, it is not possible to update the disk offering. The fix is to disallow migration from shared to local store. Migrating the data volume from NFS to local storage ,underlying disk offering is not changed. - Key: CLOUDSTACK-4551 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4551 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: manasaveloori Assignee: Koushik Das Priority: Critical Fix For: 4.2.1 .Steps: 1.Have CS with 4.2 build. 2.Have 2 primary storages NFS and local,NFS secondary. 3.Create disk offering using local storage. 4.Create a data volume using NFS. 5.Now migrate the volume to local primary storage. Observation: Volume is getting migrated ad storage is changed from NFS to local but the underlying disk offering is not changed. Disk offering with which NFS volume is created id: 3 domain_id: NULL name: Small uuid: d5b03402-9136-476f-9333-7db89def7b12 display_text: Small Disk, 5 GB disk_size: 5368709120 type: Disk tags: NULL recreatable: 0 use_local_storage: 0 unique_name: Cloud.Com-Small system_use: 0 customized: 0 removed: NULL created: 2013-08-29 11:23:41 sort_key: 0 display_offering: 1 customized_iops: NULL min_iops: NULL max_iops: NULL bytes_read_rate: NULL bytes_write_rate: NULL iops_read_rate: NULL iops_write_rate: NULL volume created using NFS mysql select * from volumes where name = sharedBU\G; *** 1. row *** id: 7 account_id: 2 domain_id: 1 pool_id: 201 last_pool_id: NULL instance_id: NULL device_id: NULL name: sharedBU uuid: 945073f2-1680-4e22-af35-9d7c0bb12486 size: 5368709120 folder: /export/home/manasa/primaryVMw path: d52a77ff39c54c499441661ca0af789a pod_id: 1 data_center_id: 1 iscsi_name: NULL host_ip: NULL volume_type: DATADISK pool_type: NetworkFilesystem disk_offering_id: 3 template_id: NULL iso_id: NULL first_snapshot_backup_uuid: NULL recreatable: 0 created: 2013-08-29 12:02:08 attached: NULL updated: 2013-08-29 13:59:42 removed: NULL state: Ready chain_info: NULL update_count: 2 disk_type: NULL vm_snapshot_chain_size: NULL display_volume: 1 format: OVA min_iops: NULL max_iops: NULL 1 row in set (0.00 sec) Volume after migrating to local primary storage. id: 20 account_id: 2 domain_id: 1 pool_id: 200 last_pool_id: 201 instance_id: NULL device_id: NULL name: sharedBU uuid: 0074a14a-ee89-425a-a745-cef7bef6425b size: 5368709120 folder: datastore-14964 path: 9389f319093c4ef9907e16538fe21779 pod_id: 1 data_center_id: 1 iscsi_name: NULL host_ip: NULL volume_type: DATADISK pool_type: NULL disk_offering_id: 3 template_id: NULL iso_id: 0 first_snapshot_backup_uuid: NULL recreatable: 0 created: 2013-08-29 14:34:09 attached: NULL
[jira] [Commented] (CLOUDSTACK-4624) VM Migration fails in 'Security Group Enabled Advanced Zone' with CloudRuntimeException: callHostPlugin failed for cmd: network_rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797789#comment-13797789
]
Wei Zhou commented on CLOUDSTACK-4624:
--
Does /var/run/cloud/ directory exist on your host?
VM Migration fails in 'Security Group Enabled Advanced Zone' with
CloudRuntimeException: callHostPlugin failed for cmd: network_rules
-
Key: CLOUDSTACK-4624
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4624
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: XenServer
Affects Versions: 4.2.0, Future
Environment: CloudStack 4.2.0 with XenServer 6.1 or 6.2
Reporter: Paul Angus
Assignee: Jayapal Reddy
Priority: Critical
Fix For: 4.2.1
VM Migration fails in a 'Security Group Enabled Advanced Zone' with
CloudRuntimeException: callHostPlugin failed for cmd: network_rules
013-09-06 14:18:07,711 DEBUG [network.security.SecurityGroupManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
Group Mgr v2: scheduling ruleset updates for 1 vms (unique=1), current queue
size=0
2013-09-06 14:18:07,715 DEBUG [network.security.SecurityGroupManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
Group Mgr v2: done scheduling ruleset updates for 1 vms: num new jobs=1 num
rows insert or updated=1 time taken=4
2013-09-06 14:18:07,715 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) VM state
transitted from :Migrating to Running with event: OperationSucceededvm's
original host id: 7 new host id: 8 host id before state transition: 8
2013-09-06 14:18:07,721 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-244:null) Ping from 5
2013-09-06 14:18:07,728 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
actual total CPU: 63840 and CPU after applying overprovisioning: 127680
2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
actual total RAM: 267404820480 and RAM after applying overprovisioning:
267404820480
2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
cpu from host: 7, old used: 1000,reserved: 0, actual total: 63840, total with
overprovisioning: 127680; new used: 0,reserved:0; movedfromreserved:
false,moveToReserveredfalse
2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
mem from host: 7, old used: 1073741824,reserved: 0, total: 267404820480; new
used: 0,reserved:0; movedfromreserved: false,moveToReserveredfalse
2013-09-06 14:18:07,731 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null)
===START=== 10.67.9.233 -- GET
command=queryAsyncJobResultjobId=16e9e8e3-460e-4a72-a455-d65b01f3b360response=jsonsessionkey=hLoqoRm93LQk67lSOtoBQZludFg%3D_=1378473487668
2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
8-576979043: Sending { Cmd , MgmtId: 345052351047, via: 8, Ver: v1, Flags:
100011,
[{com.cloud.agent.api.CheckVirtualMachineCommand:{vmName:i-2-11-VM,wait:20}}]
}
2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
8-576979043: Executing: { Cmd , MgmtId: 345052351047, via: 8, Ver: v1,
Flags: 100011,
[{com.cloud.agent.api.CheckVirtualMachineCommand:{vmName:i-2-11-VM,wait:20}}]
}
2013-09-06 14:18:07,739 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-436:null) Seq 8-576979043: Executing request
2013-09-06 14:18:07,747 DEBUG [network.security.SecurityGroupManagerImpl]
(SecGrp-Worker-41:null) SecurityGroupManager v2: sending ruleset update for
vm i-2-11-VM:ingress num rules=4:egress num rules=0 num cidrs=6
sig=8ccd7a72119d5c8180377d3cd847c10f
2013-09-06 14:18:07,750 DEBUG [agent.transport.Request]
(SecGrp-Worker-41:null) Seq 8-576979044: Sending { Cmd , MgmtId:
345052351047, via: 8, Ver: v1, Flags: 100111,
[jira] [Comment Edited] (CLOUDSTACK-4624) VM Migration fails in 'Security Group Enabled Advanced Zone' with CloudRuntimeException: callHostPlugin failed for cmd: network_rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797789#comment-13797789
]
Wei Zhou edited comment on CLOUDSTACK-4624 at 10/17/13 11:03 AM:
-
Does /var/run/cloud/ directory exist on your host?
If not, create it and try again
was (Author: weizhou):
Does /var/run/cloud/ directory exist on your host?
VM Migration fails in 'Security Group Enabled Advanced Zone' with
CloudRuntimeException: callHostPlugin failed for cmd: network_rules
-
Key: CLOUDSTACK-4624
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4624
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: XenServer
Affects Versions: 4.2.0, Future
Environment: CloudStack 4.2.0 with XenServer 6.1 or 6.2
Reporter: Paul Angus
Assignee: Jayapal Reddy
Priority: Critical
Fix For: 4.2.1
VM Migration fails in a 'Security Group Enabled Advanced Zone' with
CloudRuntimeException: callHostPlugin failed for cmd: network_rules
013-09-06 14:18:07,711 DEBUG [network.security.SecurityGroupManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
Group Mgr v2: scheduling ruleset updates for 1 vms (unique=1), current queue
size=0
2013-09-06 14:18:07,715 DEBUG [network.security.SecurityGroupManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
Group Mgr v2: done scheduling ruleset updates for 1 vms: num new jobs=1 num
rows insert or updated=1 time taken=4
2013-09-06 14:18:07,715 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) VM state
transitted from :Migrating to Running with event: OperationSucceededvm's
original host id: 7 new host id: 8 host id before state transition: 8
2013-09-06 14:18:07,721 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-244:null) Ping from 5
2013-09-06 14:18:07,728 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
actual total CPU: 63840 and CPU after applying overprovisioning: 127680
2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
actual total RAM: 267404820480 and RAM after applying overprovisioning:
267404820480
2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
cpu from host: 7, old used: 1000,reserved: 0, actual total: 63840, total with
overprovisioning: 127680; new used: 0,reserved:0; movedfromreserved:
false,moveToReserveredfalse
2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
mem from host: 7, old used: 1073741824,reserved: 0, total: 267404820480; new
used: 0,reserved:0; movedfromreserved: false,moveToReserveredfalse
2013-09-06 14:18:07,731 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null)
===START=== 10.67.9.233 -- GET
command=queryAsyncJobResultjobId=16e9e8e3-460e-4a72-a455-d65b01f3b360response=jsonsessionkey=hLoqoRm93LQk67lSOtoBQZludFg%3D_=1378473487668
2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
8-576979043: Sending { Cmd , MgmtId: 345052351047, via: 8, Ver: v1, Flags:
100011,
[{com.cloud.agent.api.CheckVirtualMachineCommand:{vmName:i-2-11-VM,wait:20}}]
}
2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
8-576979043: Executing: { Cmd , MgmtId: 345052351047, via: 8, Ver: v1,
Flags: 100011,
[{com.cloud.agent.api.CheckVirtualMachineCommand:{vmName:i-2-11-VM,wait:20}}]
}
2013-09-06 14:18:07,739 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-436:null) Seq 8-576979043: Executing request
2013-09-06 14:18:07,747 DEBUG [network.security.SecurityGroupManagerImpl]
(SecGrp-Worker-41:null) SecurityGroupManager v2: sending ruleset update for
vm i-2-11-VM:ingress num rules=4:egress num rules=0 num cidrs=6
sig=8ccd7a72119d5c8180377d3cd847c10f
2013-09-06 14:18:07,750 DEBUG [agent.transport.Request]
(SecGrp-Worker-41:null) Seq 8-576979044: Sending { Cmd , MgmtId:
345052351047, via: 8, Ver: v1, Flags: 100111,
[jira] [Commented] (CLOUDSTACK-4624) VM Migration fails in 'Security Group Enabled Advanced Zone' with CloudRuntimeException: callHostPlugin failed for cmd: network_rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797793#comment-13797793
]
Paul Angus commented on CLOUDSTACK-4624:
Yes, /var/run/cloud does exist, and it contains i-2-76-VM.log and r-32-VM.log.
i-2-76-VM.log contains:
i-2-76-VM,76,[IP_REDACTED],12,2602c3ba6866a7a5d48335c74c185df5,1,06:f8:32:00:05:32
VM Migration fails in 'Security Group Enabled Advanced Zone' with
CloudRuntimeException: callHostPlugin failed for cmd: network_rules
-
Key: CLOUDSTACK-4624
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4624
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: XenServer
Affects Versions: 4.2.0, Future
Environment: CloudStack 4.2.0 with XenServer 6.1 or 6.2
Reporter: Paul Angus
Assignee: Jayapal Reddy
Priority: Critical
Fix For: 4.2.1
VM Migration fails in a 'Security Group Enabled Advanced Zone' with
CloudRuntimeException: callHostPlugin failed for cmd: network_rules
013-09-06 14:18:07,711 DEBUG [network.security.SecurityGroupManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
Group Mgr v2: scheduling ruleset updates for 1 vms (unique=1), current queue
size=0
2013-09-06 14:18:07,715 DEBUG [network.security.SecurityGroupManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Security
Group Mgr v2: done scheduling ruleset updates for 1 vms: num new jobs=1 num
rows insert or updated=1 time taken=4
2013-09-06 14:18:07,715 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) VM state
transitted from :Migrating to Running with event: OperationSucceededvm's
original host id: 7 new host id: 8 host id before state transition: 8
2013-09-06 14:18:07,721 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-244:null) Ping from 5
2013-09-06 14:18:07,728 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
actual total CPU: 63840 and CPU after applying overprovisioning: 127680
2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Hosts's
actual total RAM: 267404820480 and RAM after applying overprovisioning:
267404820480
2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
cpu from host: 7, old used: 1000,reserved: 0, actual total: 63840, total with
overprovisioning: 127680; new used: 0,reserved:0; movedfromreserved:
false,moveToReserveredfalse
2013-09-06 14:18:07,729 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) release
mem from host: 7, old used: 1073741824,reserved: 0, total: 267404820480; new
used: 0,reserved:0; movedfromreserved: false,moveToReserveredfalse
2013-09-06 14:18:07,731 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null)
===START=== 10.67.9.233 -- GET
command=queryAsyncJobResultjobId=16e9e8e3-460e-4a72-a455-d65b01f3b360response=jsonsessionkey=hLoqoRm93LQk67lSOtoBQZludFg%3D_=1378473487668
2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
8-576979043: Sending { Cmd , MgmtId: 345052351047, via: 8, Ver: v1, Flags:
100011,
[{com.cloud.agent.api.CheckVirtualMachineCommand:{vmName:i-2-11-VM,wait:20}}]
}
2013-09-06 14:18:07,738 DEBUG [agent.transport.Request]
(Job-Executor-16:job-64 = [ 16e9e8e3-460e-4a72-a455-d65b01f3b360 ]) Seq
8-576979043: Executing: { Cmd , MgmtId: 345052351047, via: 8, Ver: v1,
Flags: 100011,
[{com.cloud.agent.api.CheckVirtualMachineCommand:{vmName:i-2-11-VM,wait:20}}]
}
2013-09-06 14:18:07,739 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-436:null) Seq 8-576979043: Executing request
2013-09-06 14:18:07,747 DEBUG [network.security.SecurityGroupManagerImpl]
(SecGrp-Worker-41:null) SecurityGroupManager v2: sending ruleset update for
vm i-2-11-VM:ingress num rules=4:egress num rules=0 num cidrs=6
sig=8ccd7a72119d5c8180377d3cd847c10f
2013-09-06 14:18:07,750 DEBUG [agent.transport.Request]
(SecGrp-Worker-41:null) Seq 8-576979044: Sending { Cmd , MgmtId:
345052351047, via: 8, Ver: v1, Flags: 100111,
[jira] [Commented] (CLOUDSTACK-4766) [Automation] test_reset_ssh_keypair executing in infinite loop and regression suite hang
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797809#comment-13797809 ] ASF subversion and git services commented on CLOUDSTACK-4766: - Commit e3bcdc16a11d7452b5bf6ce5e5993dcd008526a6 in branch refs/heads/4.2 from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e3bcdc1 ] CLOUDSTACK-4766: Add timeout if vm does not reach running state The tests use to wait for ever for the vm to attain Running state. Added a timeout so it does not get into infinite loop. Signed-off-by: venkataswamybabu budumuru venkataswamybabu.budum...@citrix.com [Automation] test_reset_ssh_keypair executing in infinite loop and regression suite hang Key: CLOUDSTACK-4766 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4766 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.1 Environment: Automation advanced zone Reporter: Rayees Namathponnan Assignee: Girish Shilamkar Priority: Blocker Fix For: 4.2.1 Few test cases from test_reset_ssh_keypair.py suite executing infinite loop hang automation See the below code from test_reset_ssh_keypair.py, here test case checking VM's state in every 60 sec, due to some reason if this vm never comes to running; this code will execute in a loop 578 while True: 579 vms = VirtualMachine.list( 580 self.apiclient, 581 account=self.account.name, 582 domainid=self.account.domainid, 583 listall=True 584 ) 585 if vms[0].state == Running: 586 break 587 self.debug(Vm not in Running state sleep 60s) 588 time.sleep(60) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4766) [Automation] test_reset_ssh_keypair executing in infinite loop and regression suite hang
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797810#comment-13797810 ] ASF subversion and git services commented on CLOUDSTACK-4766: - Commit 9cc557509265d8faacca134e8bfeb3a31ddbeb31 in branch refs/heads/master from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9cc5575 ] CLOUDSTACK-4766: Add timeout if vm does not reach running state The tests use to wait for ever for the vm to attain Running state. Added a timeout so it does not get into infinite loop. Signed-off-by: venkataswamybabu budumuru venkataswamybabu.budum...@citrix.com (cherry picked from commit e3bcdc16a11d7452b5bf6ce5e5993dcd008526a6) [Automation] test_reset_ssh_keypair executing in infinite loop and regression suite hang Key: CLOUDSTACK-4766 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4766 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.1 Environment: Automation advanced zone Reporter: Rayees Namathponnan Assignee: Girish Shilamkar Priority: Blocker Fix For: 4.2.1 Few test cases from test_reset_ssh_keypair.py suite executing infinite loop hang automation See the below code from test_reset_ssh_keypair.py, here test case checking VM's state in every 60 sec, due to some reason if this vm never comes to running; this code will execute in a loop 578 while True: 579 vms = VirtualMachine.list( 580 self.apiclient, 581 account=self.account.name, 582 domainid=self.account.domainid, 583 listall=True 584 ) 585 if vms[0].state == Running: 586 break 587 self.debug(Vm not in Running state sleep 60s) 588 time.sleep(60) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-702) Multiple IP Ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797812#comment-13797812 ] ASF subversion and git services commented on CLOUDSTACK-702: Commit 7a7fb61a17911987838a2b6744d594c840df7c2e in branch refs/heads/master from [~sanjeevn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7a7fb61 ] CLOUDSTACK-702: Verify Userdata,password services 1.Added two tests to vefiy userdata and password services on alias ip on VR Conflicts: test/integration/component/maint/test_multiple_ip_ranges.py Signed-off-by: sanjeevneelarapu sanjeev.neelar...@citrix.com Signed-off-by: venkataswamybabu budumuru venkataswamybabu.budum...@citrix.com Multiple IP Ranges -- Key: CLOUDSTACK-702 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-702 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Manan Shah Assignee: Bharat Kumar Fix For: 4.2.0 Requirements described at: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+Ranges Requirements discussion email thread link: http://markmail.org/search/?q=[ASFCS41]+Multiple+IP+Ranges+list%3Aorg.apache.incubator.cloudstack-dev -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-702) Multiple IP Ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797813#comment-13797813 ] ASF subversion and git services commented on CLOUDSTACK-702: Commit 8b0894b27c45c3e89824ece3a6c47c8143d3ae76 in branch refs/heads/4.2 from [~sanjeevn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8b0894b ] CLOUDSTACK-702: Verify Userdata,password services 1.Added two tests to vefiy userdata and password services on alias ip on VR Conflicts: test/integration/component/maint/test_multiple_ip_ranges.py Signed-off-by: sanjeevneelarapu sanjeev.neelar...@citrix.com Signed-off-by: venkataswamybabu budumuru venkataswamybabu.budum...@citrix.com (cherry picked from commit 7a7fb61a17911987838a2b6744d594c840df7c2e) Multiple IP Ranges -- Key: CLOUDSTACK-702 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-702 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Manan Shah Assignee: Bharat Kumar Fix For: 4.2.0 Requirements described at: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+Ranges Requirements discussion email thread link: http://markmail.org/search/?q=[ASFCS41]+Multiple+IP+Ranges+list%3Aorg.apache.incubator.cloudstack-dev -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-4792: --- Fix Version/s: 4.2.1 Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3840) [Automation] test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters failed to raise expected Exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797819#comment-13797819
]
Jayapal Reddy commented on CLOUDSTACK-3840:
---
Hi,
From the UI it is working as expected. Please see the below MS logs.
Please check the test case.
2013-10-17 17:28:53,317 DEBUG [cloud.api.ApiServlet]
(1074250461@qtp-1443430503-11:null) ===START=== 10.252.192.106 -- GET
command=authorizeSecurityGroupEgressresponse=jsonsessionkey=CwR0dunRxGVTa5qyt1l%2B5IpwC4Y%3Dsecuritygroupid=b25e3468-36f5-11e3-a5d4-0a5aa429deddprotocol=tcpdomainid=6b161f1c-36f5-11e3-a5d4-0a5aa429deddaccount=adminstartport=22endport=22cidrlist=0.0.0.10_=1382011133303
2013-10-17 17:28:53,346 DEBUG [cloud.async.AsyncJobManagerImpl]
(1074250461@qtp-1443430503-11:null) submit async job-17 = [
c84d5f5c-7d6a-4242-b2d0-aaa60f83712e ], details: AsyncJobVO {id:17, userId: 2,
accountId: 2, sessionKey: null, instanceType: SecurityGroup, instanceId: 1,
cmd:
org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupEgressCmd,
cmdOriginator: null, cmdInfo:
{sessionkey:CwR0dunRxGVTa5qyt1l+5IpwC4Y\u003d,protocol:tcp,cmdEventType:SG.AUTH.EGRESS,ctxUserId:2,securitygroupid:b25e3468-36f5-11e3-a5d4-0a5aa429dedd,httpmethod:GET,startport:22,domainid:6b161f1c-36f5-11e3-a5d4-0a5aa429dedd,endport:22,response:json,cidrlist:0.0.0.10,account:admin,_:1382011133303,ctxAccountId:2,ctxStartEventId:70},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 1, completeMsid: null,
lastUpdated: null, lastPolled: null, created: null}
2013-10-17 17:28:53,347 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-4:job-17 = [ c84d5f5c-7d6a-4242-b2d0-aaa60f83712e ]) Executing
org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupEgressCmd
for job-17 = [ c84d5f5c-7d6a-4242-b2d0-aaa60f83712e ]
2013-10-17 17:28:53,349 DEBUG [cloud.api.ApiServlet]
(1074250461@qtp-1443430503-11:null) ===END=== 10.252.192.106 -- GET
command=authorizeSecurityGroupEgressresponse=jsonsessionkey=CwR0dunRxGVTa5qyt1l%2B5IpwC4Y%3Dsecuritygroupid=b25e3468-36f5-11e3-a5d4-0a5aa429deddprotocol=tcpdomainid=6b161f1c-36f5-11e3-a5d4-0a5aa429deddaccount=adminstartport=22endport=22cidrlist=0.0.0.10_=1382011133303
2013-10-17 17:28:53,377 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-4:job-17 = [ c84d5f5c-7d6a-4242-b2d0-aaa60f83712e ]) Unexpected
exception while executing
org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupEgressCmd
com.cloud.exception.InvalidParameterValueException: Invalid cidr 0.0.0.10
at
com.cloud.network.security.SecurityGroupManagerImpl.authorizeSecurityGroupRule(SecurityGroupManagerImpl.java:606)
249
2013-10-17 17:25:12,302 DEBUG [cloud.async.AsyncJobManagerImpl]
(1074250461@qtp-1443430503-11:null) submit async job-16 = [
0b1d5086-584f-41a5-bda6-85f81b07132b ], details: AsyncJobVO {id:16, userId: 2,
accountId: 2, sessionKey: null, instanceType: SecurityGroup, instanceId: 1,
cmd:
org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupEgressCmd,
cmdOriginator: null, cmdInfo:
{sessionkey:CwR0dunRxGVTa5qyt1l+5IpwC4Y\u003d,protocol:tcp,cmdEventType:SG.AUTH.EGRESS,ctxUserId:2,securitygroupid:b25e3468-36f5-11e3-a5d4-0a5aa429dedd,httpmethod:GET,startport:22,domainid:6b161f1c-36f5-11e3-a5d4-0a5aa429dedd,endport:22,response:json,cidrlist:0.0.0.0/33,account:admin,_:1382010912249,ctxAccountId:2,ctxStartEventId:67},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 1, completeMsid: null,
lastUpdated: null, lastPolled: null, created: null}
2013-10-17 17:25:12,304 DEBUG [cloud.api.ApiServlet]
(1074250461@qtp-1443430503-11:null) ===END=== 10.252.192.106 -- GET
command=authorizeSecurityGroupEgressresponse=jsonsessionkey=CwR0dunRxGVTa5qyt1l%2B5IpwC4Y%3Dsecuritygroupid=b25e3468-36f5-11e3-a5d4-0a5aa429deddprotocol=tcpdomainid=6b161f1c-36f5-11e3-a5d4-0a5aa429deddaccount=adminstartport=22endport=22cidrlist=0.0.0.0%2F33_=1382010912249
2013-10-17 17:25:12,321 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-3:job-16 = [ 0b1d5086-584f-41a5-bda6-85f81b07132b ]) Executing
org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupEgressCmd
for job-16 = [ 0b1d5086-584f-41a5-bda6-85f81b07132b ]
2013-10-17 17:25:12,351 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-3:job-16 = [ 0b1d5086-584f-41a5-bda6-85f81b07132b ]) Unexpected
exception while executing
org.apache.cloudstack.api.command.user.securitygroup.AuthorizeSecurityGroupEgressCmd
com.cloud.exception.InvalidParameterValueException: Invalid cidr 0.0.0.0/33
at
com.cloud.network.security.SecurityGroupManagerImpl.authorizeSecurityGroupRule(SecurityGroupManagerImpl.java:606)
[Automation]
[jira] [Assigned] (CLOUDSTACK-3840) [Automation] test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters failed to raise expected Exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy reassigned CLOUDSTACK-3840:
-
Assignee: Jayapal Reddy (was: venkata swamybabu budumuru)
[Automation]
test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters
failed to raise expected Exception
-
Key: CLOUDSTACK-3840
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3840
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, Management Server
Affects Versions: 4.2.0
Environment: Automation
Reporter: Rayees Namathponnan
Assignee: Jayapal Reddy
Fix For: 4.3.0
Test case
integration.component.test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters
failed in automation runs, observed below error
Error Message
Exception not raised
begin captured logging
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Created security
group with ID: 896d1c49-1c40-4090-97f9-922ff4060ed6
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid port
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid cidr
- 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_egress_rules.py,
line 2098, in test_invalid_parameters
domainid=self.account.domainid
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
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Created security
group with ID: 896d1c49-1c40-4090-97f9-922ff4060ed6
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid port
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid cidr
- end captured logging -
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-3840) [Automation] test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters failed to raise expected Exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy reassigned CLOUDSTACK-3840:
-
Assignee: Rayees Namathponnan (was: Jayapal Reddy)
[Automation]
test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters
failed to raise expected Exception
-
Key: CLOUDSTACK-3840
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3840
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, Management Server
Affects Versions: 4.2.0
Environment: Automation
Reporter: Rayees Namathponnan
Assignee: Rayees Namathponnan
Fix For: 4.3.0
Test case
integration.component.test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters
failed in automation runs, observed below error
Error Message
Exception not raised
begin captured logging
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Created security
group with ID: 896d1c49-1c40-4090-97f9-922ff4060ed6
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid port
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid cidr
- 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_egress_rules.py,
line 2098, in test_invalid_parameters
domainid=self.account.domainid
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
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Created security
group with ID: 896d1c49-1c40-4090-97f9-922ff4060ed6
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid port
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid cidr
- end captured logging -
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4137) KVM: After unmanaging cluster, manage cluster will not bring KVM hosts to UP state. cloud-agent on KVM hosts has to be restarted manually
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797824#comment-13797824
]
Abhinandan Prateek commented on CLOUDSTACK-4137:
Release noted as per http://bugs-ccp.citrix.com/browse/CS-16386.
KVM: After unmanaging cluster, manage cluster will not bring KVM hosts to UP
state. cloud-agent on KVM hosts has to be restarted manually
-
Key: CLOUDSTACK-4137
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4137
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.2.0
Environment: hypervisor : KVM
Reporter: prashant kumar mishra
Assignee: Kishan Kavala
Priority: Critical
Fix For: 4.2.1
Attachments: Logs_DB_Agent.rar
Steps to reproduce
---
1-prepare a CS -one cluster--one kvm(rhel6.3)
2-unmanage cluster
3-manage cluster
Expected
--
Host should come up , in running state
Actual
--
Host remain in Disconnect state
My observation
---
1-after host went in disconnect state i performed host maintenance mode
then cancel maintenance mode and host came up
2-restart cloud-agent on the kvm hosts bring the hosts to UP state
Logs:
--
2013-08-07 20:14:16,999 DEBUG [cloud.api.ApiServlet] (catalina-exec-23:null)
===START=== 10.252.192.53 -- GET
command=updateClusterid=854b547a-fbee-4eed-895d-b8ea96d1cc23managedstate=Unmanagedresponse=jsonsessionkey=vOfsgLOiksyXg%2B23XuFp6maNm1I%3D_=1375867173396
2013-08-07 20:14:17,031 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-2042691611: Sending { Cmd , MgmtId:
6703101771911, via: 1, Ver: v1, Flags: 100111,
[{com.cloud.agent.api.MaintainCommand:{wait:0}}] }
2013-08-07 20:14:17,038 DEBUG [agent.transport.Request]
(AgentManager-Handler-7:null) Seq 1-2042691611: Processing: { Ans: , MgmtId:
6703101771911, via: 1, Ver: v1, Flags: 110,
[{com.cloud.agent.api.MaintainAnswer:{willMigrate:true,result:true,wait:0}}]
}
2013-08-07 20:14:17,038 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-7:null) Seq 1-2042691611: No more commands found
2013-08-07 20:14:17,038 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-2042691611: Received: { Ans: , MgmtId:
6703101771911, via: 1, Ver: v1, Flags: 110, { MaintainAnswer } }
2013-08-07 20:14:17,039 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Host 1 is disconnecting with event ShutdownRequested
2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) The next status of agent 1is Disconnected, current
status is Up
2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Deregistering link for 1 with state Disconnected
2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Remove Agent : 1
2013-08-07 20:14:17,052 DEBUG [agent.manager.ConnectedAgentAttache]
(AgentTaskPool-4:null) Processing Disconnect.
2013-08-07 20:14:17,052 DEBUG [agent.manager.AgentAttache]
(AgentTaskPool-4:null) Seq 1-2042691586: Sending disconnect to class
com.cloud.network.security.SecurityGroupListener
2013-08-07 20:14:17,052 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.hypervisor.xen.discoverer.XcpServerDiscoverer_EnhancerByCloudStack_eccb8bca
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.deploy.DeploymentPlanningManagerImpl_EnhancerByCloudStack_b3901640
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.network.NetworkManagerImpl_EnhancerByCloudStack_c52127d3
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.storage.secondary.SecondaryStorageListener
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.hypervisor.vmware.manager.VmwareManagerImpl_EnhancerByCloudStack_5c9626cd
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.network.security.SecurityGroupListener
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.storage.listener.StoragePoolMonitor
2013-08-07 20:14:17,054 DEBUG [agent.manager.AgentManagerImpl]
[jira] [Updated] (CLOUDSTACK-4137) KVM: After unmanaging cluster, manage cluster will not bring KVM hosts to UP state. cloud-agent on KVM hosts has to be restarted manually
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinandan Prateek updated CLOUDSTACK-4137:
---
Labels: ReleaseNote (was: )
KVM: After unmanaging cluster, manage cluster will not bring KVM hosts to UP
state. cloud-agent on KVM hosts has to be restarted manually
-
Key: CLOUDSTACK-4137
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4137
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.2.0
Environment: hypervisor : KVM
Reporter: prashant kumar mishra
Assignee: Kishan Kavala
Priority: Critical
Labels: ReleaseNote
Fix For: 4.2.1
Attachments: Logs_DB_Agent.rar
Steps to reproduce
---
1-prepare a CS -one cluster--one kvm(rhel6.3)
2-unmanage cluster
3-manage cluster
Expected
--
Host should come up , in running state
Actual
--
Host remain in Disconnect state
My observation
---
1-after host went in disconnect state i performed host maintenance mode
then cancel maintenance mode and host came up
2-restart cloud-agent on the kvm hosts bring the hosts to UP state
Logs:
--
2013-08-07 20:14:16,999 DEBUG [cloud.api.ApiServlet] (catalina-exec-23:null)
===START=== 10.252.192.53 -- GET
command=updateClusterid=854b547a-fbee-4eed-895d-b8ea96d1cc23managedstate=Unmanagedresponse=jsonsessionkey=vOfsgLOiksyXg%2B23XuFp6maNm1I%3D_=1375867173396
2013-08-07 20:14:17,031 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-2042691611: Sending { Cmd , MgmtId:
6703101771911, via: 1, Ver: v1, Flags: 100111,
[{com.cloud.agent.api.MaintainCommand:{wait:0}}] }
2013-08-07 20:14:17,038 DEBUG [agent.transport.Request]
(AgentManager-Handler-7:null) Seq 1-2042691611: Processing: { Ans: , MgmtId:
6703101771911, via: 1, Ver: v1, Flags: 110,
[{com.cloud.agent.api.MaintainAnswer:{willMigrate:true,result:true,wait:0}}]
}
2013-08-07 20:14:17,038 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-7:null) Seq 1-2042691611: No more commands found
2013-08-07 20:14:17,038 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-2042691611: Received: { Ans: , MgmtId:
6703101771911, via: 1, Ver: v1, Flags: 110, { MaintainAnswer } }
2013-08-07 20:14:17,039 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Host 1 is disconnecting with event ShutdownRequested
2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) The next status of agent 1is Disconnected, current
status is Up
2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Deregistering link for 1 with state Disconnected
2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Remove Agent : 1
2013-08-07 20:14:17,052 DEBUG [agent.manager.ConnectedAgentAttache]
(AgentTaskPool-4:null) Processing Disconnect.
2013-08-07 20:14:17,052 DEBUG [agent.manager.AgentAttache]
(AgentTaskPool-4:null) Seq 1-2042691586: Sending disconnect to class
com.cloud.network.security.SecurityGroupListener
2013-08-07 20:14:17,052 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.hypervisor.xen.discoverer.XcpServerDiscoverer_EnhancerByCloudStack_eccb8bca
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.deploy.DeploymentPlanningManagerImpl_EnhancerByCloudStack_b3901640
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.network.NetworkManagerImpl_EnhancerByCloudStack_c52127d3
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.storage.secondary.SecondaryStorageListener
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.hypervisor.vmware.manager.VmwareManagerImpl_EnhancerByCloudStack_5c9626cd
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.network.security.SecurityGroupListener
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.storage.listener.StoragePoolMonitor
2013-08-07 20:14:17,054 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
[jira] [Resolved] (CLOUDSTACK-4137) KVM: After unmanaging cluster, manage cluster will not bring KVM hosts to UP state. cloud-agent on KVM hosts has to be restarted manually
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinandan Prateek resolved CLOUDSTACK-4137.
Resolution: Won't Fix
Masked as release noted.
KVM: After unmanaging cluster, manage cluster will not bring KVM hosts to UP
state. cloud-agent on KVM hosts has to be restarted manually
-
Key: CLOUDSTACK-4137
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4137
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.2.0
Environment: hypervisor : KVM
Reporter: prashant kumar mishra
Assignee: Kishan Kavala
Priority: Critical
Labels: ReleaseNote
Fix For: 4.2.1
Attachments: Logs_DB_Agent.rar
Steps to reproduce
---
1-prepare a CS -one cluster--one kvm(rhel6.3)
2-unmanage cluster
3-manage cluster
Expected
--
Host should come up , in running state
Actual
--
Host remain in Disconnect state
My observation
---
1-after host went in disconnect state i performed host maintenance mode
then cancel maintenance mode and host came up
2-restart cloud-agent on the kvm hosts bring the hosts to UP state
Logs:
--
2013-08-07 20:14:16,999 DEBUG [cloud.api.ApiServlet] (catalina-exec-23:null)
===START=== 10.252.192.53 -- GET
command=updateClusterid=854b547a-fbee-4eed-895d-b8ea96d1cc23managedstate=Unmanagedresponse=jsonsessionkey=vOfsgLOiksyXg%2B23XuFp6maNm1I%3D_=1375867173396
2013-08-07 20:14:17,031 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-2042691611: Sending { Cmd , MgmtId:
6703101771911, via: 1, Ver: v1, Flags: 100111,
[{com.cloud.agent.api.MaintainCommand:{wait:0}}] }
2013-08-07 20:14:17,038 DEBUG [agent.transport.Request]
(AgentManager-Handler-7:null) Seq 1-2042691611: Processing: { Ans: , MgmtId:
6703101771911, via: 1, Ver: v1, Flags: 110,
[{com.cloud.agent.api.MaintainAnswer:{willMigrate:true,result:true,wait:0}}]
}
2013-08-07 20:14:17,038 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-7:null) Seq 1-2042691611: No more commands found
2013-08-07 20:14:17,038 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-2042691611: Received: { Ans: , MgmtId:
6703101771911, via: 1, Ver: v1, Flags: 110, { MaintainAnswer } }
2013-08-07 20:14:17,039 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Host 1 is disconnecting with event ShutdownRequested
2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) The next status of agent 1is Disconnected, current
status is Up
2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Deregistering link for 1 with state Disconnected
2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Remove Agent : 1
2013-08-07 20:14:17,052 DEBUG [agent.manager.ConnectedAgentAttache]
(AgentTaskPool-4:null) Processing Disconnect.
2013-08-07 20:14:17,052 DEBUG [agent.manager.AgentAttache]
(AgentTaskPool-4:null) Seq 1-2042691586: Sending disconnect to class
com.cloud.network.security.SecurityGroupListener
2013-08-07 20:14:17,052 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.hypervisor.xen.discoverer.XcpServerDiscoverer_EnhancerByCloudStack_eccb8bca
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.deploy.DeploymentPlanningManagerImpl_EnhancerByCloudStack_b3901640
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.network.NetworkManagerImpl_EnhancerByCloudStack_c52127d3
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.storage.secondary.SecondaryStorageListener
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.hypervisor.vmware.manager.VmwareManagerImpl_EnhancerByCloudStack_5c9626cd
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.network.security.SecurityGroupListener
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.storage.listener.StoragePoolMonitor
2013-08-07 20:14:17,054 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to
[jira] [Assigned] (CLOUDSTACK-2232) Automation: Add automation for Persistent networks without running a VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye reassigned CLOUDSTACK-2232: -- Assignee: Gaurav Aradhye Automation: Add automation for Persistent networks without running a VM Key: CLOUDSTACK-2232 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2232 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sudha Ponnaganti Assignee: Gaurav Aradhye Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3840) [Automation] test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters failed to raise expected Exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797833#comment-13797833
]
Jayapal Reddy commented on CLOUDSTACK-3840:
---
The CIDR validation issue got fixed, please check test case again.
ASF subversion and git services added a comment - 03/Sep/13 14:28
Commit 7aea599eb4f16fc919a7556d5800f105a99b708e in branch refs/heads/master
from Jayapal Reddy
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7aea599 ]
CLOUDSTACK-4586 Added CIDR validation for SG Egress rules
[Automation]
test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters
failed to raise expected Exception
-
Key: CLOUDSTACK-3840
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3840
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, Management Server
Affects Versions: 4.2.0
Environment: Automation
Reporter: Rayees Namathponnan
Assignee: Rayees Namathponnan
Fix For: 4.3.0
Test case
integration.component.test_egress_rules.TestInvalidParametersForEgress.test_invalid_parameters
failed in automation runs, observed below error
Error Message
Exception not raised
begin captured logging
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Created security
group with ID: 896d1c49-1c40-4090-97f9-922ff4060ed6
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid port
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid cidr
- 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_egress_rules.py,
line 2098, in test_invalid_parameters
domainid=self.account.domainid
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
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Created security
group with ID: 896d1c49-1c40-4090-97f9-922ff4060ed6
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid port
testclient.testcase.TestInvalidParametersForEgress: DEBUG: Authorizing egress
rule for sec group ID: 896d1c49-1c40-4090-97f9-922ff4060ed6 with invalid cidr
- end captured logging -
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3994) Wrong error notification is generated when Primary storage (Cluster wide) is added with wrong path
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797889#comment-13797889
]
ASF subversion and git services commented on CLOUDSTACK-3994:
-
Commit f52533c819b46483cda6647e0a9ae30a7558acea in branch refs/heads/4.2 from
[~anshulg]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f52533c ]
CLOUDSTACK-3994: fix for Wrong error notification is generated when Primary
storage is added with wrong path
Signed-off-by: Sateesh Chodapuneedi sate...@apache.org
Wrong error notification is generated when Primary storage (Cluster wide) is
added with wrong path
--
Key: CLOUDSTACK-3994
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3994
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller, VMware
Affects Versions: 4.2.0
Reporter: Sailaja Mada
Priority: Minor
Fix For: 4.3.0
Attachments: apilog.log, management-server.log
Steps:
1. Configure Adv Zone with VMWARE
2. Tried to add wrong cluster wide primary storage point
It failed saying Failed to delete storage pool on host
2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-230:null) Seq 1-757532143: Executing request
2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-230:null) Seq 1-757532143: Response Received:
2013-08-01 10:00:12,929 DEBUG [agent.transport.Request]
(DirectAgent-230:null) Seq 1-757532143: Processing: { Ans: , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:true,details:success,wait:0}}]
}
2013-08-01 10:00:12,933 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-757532143: Received: { Ans: , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 10, { Answer } }
2013-08-01 10:00:12,933 DEBUG [agent.manager.AgentManagerImpl]
(catalina-exec-23:null) Details from executing class
com.cloud.agent.api.CreateStoragePoolCommand: success
2013-08-01 10:00:12,933 DEBUG
[datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl]
(catalina-exec-23:null) In createPool Adding the pool to each of the hosts
2013-08-01 10:00:12,935 DEBUG [cloud.storage.StorageManagerImpl]
(catalina-exec-23:null) Adding pool null to host 1
2013-08-01 10:00:12,940 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-757532144: Sending { Cmd , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 100011,
[{com.cloud.agent.api.ModifyStoragePoolCommand:{add:true,pool:{id:5,uuid:86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,host:10.102.192.100,path:/cpg_vol/sailaja/ps1,port:2049,type:NetworkFilesystem},localPath:/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,wait:0}}]
}
2013-08-01 10:00:12,941 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-757532144: Executing: { Cmd , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 100011,
[{com.cloud.agent.api.ModifyStoragePoolCommand:{add:true,pool:{id:5,uuid:86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,host:10.102.192.100,path:/cpg_vol/sailaja/ps1,port:2049,type:NetworkFilesystem},localPath:/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,wait:0}}]
}
2013-08-01 10:00:12,941 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-230:null) Seq 1-757532144: Executing request
2013-08-01 10:00:12,942 INFO [vmware.resource.VmwareResource]
(DirectAgent-230:10.102.192.18) Executing resource ModifyStoragePoolCommand:
{add:true,pool:{id:5,uuid:86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,host:10.102.192.100,path:/cpg_vol/sailaja/ps1,port:2049,type:NetworkFilesystem},localPath:/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,wait:0}
2013-08-01 10:00:13,144 INFO [vmware.mo.HostMO]
(DirectAgent-230:10.102.192.18) Creation of NFS datastore on vCenter failed.
Details: vCenter API trace - mountDatastore(). target MOR: host-8973, vmfs:
false, poolHost: 10.102.192.100, poolHostPort: 2049, poolPath:
/cpg_vol/sailaja/ps1, poolUuid: 86ee525833e736f0b3c1f6029e5c8bdf. Exception
mesg: An error occurred during host configuration.
2013-08-01 10:00:13,145 ERROR [vmware.resource.VmwareResource]
(DirectAgent-230:10.102.192.18) ModifyStoragePoolCommand failed due to
Exception: java.lang.Exception
Message: Creation of NFS datastore on vCenter failed.
java.lang.Exception: Creation of NFS datastore on vCenter failed.
at
com.cloud.hypervisor.vmware.mo.HostMO.mountDatastore(HostMO.java:772)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4102)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:472)
at
[jira] [Commented] (CLOUDSTACK-3994) Wrong error notification is generated when Primary storage (Cluster wide) is added with wrong path
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797906#comment-13797906
]
ASF subversion and git services commented on CLOUDSTACK-3994:
-
Commit 93172df5569cea02cecf1c4e57646910409ffb6d in branch refs/heads/master
from [~anshulg]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=93172df ]
CLOUDSTACK-3994: fix for Wrong error notification is generated when Primary
storage is added with wrong path
Signed-off-by: Sateesh Chodapuneedi sate...@apache.org
Wrong error notification is generated when Primary storage (Cluster wide) is
added with wrong path
--
Key: CLOUDSTACK-3994
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3994
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller, VMware
Affects Versions: 4.2.0
Reporter: Sailaja Mada
Priority: Minor
Fix For: 4.3.0
Attachments: apilog.log, management-server.log
Steps:
1. Configure Adv Zone with VMWARE
2. Tried to add wrong cluster wide primary storage point
It failed saying Failed to delete storage pool on host
2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-230:null) Seq 1-757532143: Executing request
2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-230:null) Seq 1-757532143: Response Received:
2013-08-01 10:00:12,929 DEBUG [agent.transport.Request]
(DirectAgent-230:null) Seq 1-757532143: Processing: { Ans: , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:true,details:success,wait:0}}]
}
2013-08-01 10:00:12,933 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-757532143: Received: { Ans: , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 10, { Answer } }
2013-08-01 10:00:12,933 DEBUG [agent.manager.AgentManagerImpl]
(catalina-exec-23:null) Details from executing class
com.cloud.agent.api.CreateStoragePoolCommand: success
2013-08-01 10:00:12,933 DEBUG
[datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl]
(catalina-exec-23:null) In createPool Adding the pool to each of the hosts
2013-08-01 10:00:12,935 DEBUG [cloud.storage.StorageManagerImpl]
(catalina-exec-23:null) Adding pool null to host 1
2013-08-01 10:00:12,940 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-757532144: Sending { Cmd , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 100011,
[{com.cloud.agent.api.ModifyStoragePoolCommand:{add:true,pool:{id:5,uuid:86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,host:10.102.192.100,path:/cpg_vol/sailaja/ps1,port:2049,type:NetworkFilesystem},localPath:/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,wait:0}}]
}
2013-08-01 10:00:12,941 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-757532144: Executing: { Cmd , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 100011,
[{com.cloud.agent.api.ModifyStoragePoolCommand:{add:true,pool:{id:5,uuid:86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,host:10.102.192.100,path:/cpg_vol/sailaja/ps1,port:2049,type:NetworkFilesystem},localPath:/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,wait:0}}]
}
2013-08-01 10:00:12,941 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-230:null) Seq 1-757532144: Executing request
2013-08-01 10:00:12,942 INFO [vmware.resource.VmwareResource]
(DirectAgent-230:10.102.192.18) Executing resource ModifyStoragePoolCommand:
{add:true,pool:{id:5,uuid:86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,host:10.102.192.100,path:/cpg_vol/sailaja/ps1,port:2049,type:NetworkFilesystem},localPath:/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,wait:0}
2013-08-01 10:00:13,144 INFO [vmware.mo.HostMO]
(DirectAgent-230:10.102.192.18) Creation of NFS datastore on vCenter failed.
Details: vCenter API trace - mountDatastore(). target MOR: host-8973, vmfs:
false, poolHost: 10.102.192.100, poolHostPort: 2049, poolPath:
/cpg_vol/sailaja/ps1, poolUuid: 86ee525833e736f0b3c1f6029e5c8bdf. Exception
mesg: An error occurred during host configuration.
2013-08-01 10:00:13,145 ERROR [vmware.resource.VmwareResource]
(DirectAgent-230:10.102.192.18) ModifyStoragePoolCommand failed due to
Exception: java.lang.Exception
Message: Creation of NFS datastore on vCenter failed.
java.lang.Exception: Creation of NFS datastore on vCenter failed.
at
com.cloud.hypervisor.vmware.mo.HostMO.mountDatastore(HostMO.java:772)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4102)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:472)
at
[jira] [Commented] (CLOUDSTACK-3994) Wrong error notification is generated when Primary storage (Cluster wide) is added with wrong path
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797906#comment-13797906
]
ASF subversion and git services commented on CLOUDSTACK-3994:
-
Commit 93172df5569cea02cecf1c4e57646910409ffb6d in branch refs/heads/master
from [~anshulg]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=93172df ]
CLOUDSTACK-3994: fix for Wrong error notification is generated when Primary
storage is added with wrong path
Signed-off-by: Sateesh Chodapuneedi sate...@apache.org
Wrong error notification is generated when Primary storage (Cluster wide) is
added with wrong path
--
Key: CLOUDSTACK-3994
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3994
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller, VMware
Affects Versions: 4.2.0
Reporter: Sailaja Mada
Priority: Minor
Fix For: 4.3.0
Attachments: apilog.log, management-server.log
Steps:
1. Configure Adv Zone with VMWARE
2. Tried to add wrong cluster wide primary storage point
It failed saying Failed to delete storage pool on host
2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-230:null) Seq 1-757532143: Executing request
2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-230:null) Seq 1-757532143: Response Received:
2013-08-01 10:00:12,929 DEBUG [agent.transport.Request]
(DirectAgent-230:null) Seq 1-757532143: Processing: { Ans: , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:true,details:success,wait:0}}]
}
2013-08-01 10:00:12,933 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-757532143: Received: { Ans: , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 10, { Answer } }
2013-08-01 10:00:12,933 DEBUG [agent.manager.AgentManagerImpl]
(catalina-exec-23:null) Details from executing class
com.cloud.agent.api.CreateStoragePoolCommand: success
2013-08-01 10:00:12,933 DEBUG
[datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl]
(catalina-exec-23:null) In createPool Adding the pool to each of the hosts
2013-08-01 10:00:12,935 DEBUG [cloud.storage.StorageManagerImpl]
(catalina-exec-23:null) Adding pool null to host 1
2013-08-01 10:00:12,940 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-757532144: Sending { Cmd , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 100011,
[{com.cloud.agent.api.ModifyStoragePoolCommand:{add:true,pool:{id:5,uuid:86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,host:10.102.192.100,path:/cpg_vol/sailaja/ps1,port:2049,type:NetworkFilesystem},localPath:/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,wait:0}}]
}
2013-08-01 10:00:12,941 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-757532144: Executing: { Cmd , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 100011,
[{com.cloud.agent.api.ModifyStoragePoolCommand:{add:true,pool:{id:5,uuid:86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,host:10.102.192.100,path:/cpg_vol/sailaja/ps1,port:2049,type:NetworkFilesystem},localPath:/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,wait:0}}]
}
2013-08-01 10:00:12,941 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-230:null) Seq 1-757532144: Executing request
2013-08-01 10:00:12,942 INFO [vmware.resource.VmwareResource]
(DirectAgent-230:10.102.192.18) Executing resource ModifyStoragePoolCommand:
{add:true,pool:{id:5,uuid:86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,host:10.102.192.100,path:/cpg_vol/sailaja/ps1,port:2049,type:NetworkFilesystem},localPath:/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,wait:0}
2013-08-01 10:00:13,144 INFO [vmware.mo.HostMO]
(DirectAgent-230:10.102.192.18) Creation of NFS datastore on vCenter failed.
Details: vCenter API trace - mountDatastore(). target MOR: host-8973, vmfs:
false, poolHost: 10.102.192.100, poolHostPort: 2049, poolPath:
/cpg_vol/sailaja/ps1, poolUuid: 86ee525833e736f0b3c1f6029e5c8bdf. Exception
mesg: An error occurred during host configuration.
2013-08-01 10:00:13,145 ERROR [vmware.resource.VmwareResource]
(DirectAgent-230:10.102.192.18) ModifyStoragePoolCommand failed due to
Exception: java.lang.Exception
Message: Creation of NFS datastore on vCenter failed.
java.lang.Exception: Creation of NFS datastore on vCenter failed.
at
com.cloud.hypervisor.vmware.mo.HostMO.mountDatastore(HostMO.java:772)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4102)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:472)
at
[jira] [Commented] (CLOUDSTACK-3305) TemplateSync Deletes the templates in creation state from Seconday storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797980#comment-13797980 ] Marcus Sorensen commented on CLOUDSTACK-3305: - Template sync should probably look at timestamp of templates, and maybe have a global config that only cleans up templates once they're X minutes old (default 1440 or something like that). TemplateSync Deletes the templates in creation state from Seconday storage. --- Key: CLOUDSTACK-3305 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3305 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: Future this is what is happening. 1. Template creation from snapshot triggered. Work going on, but there is no update in DB that there is Work in Progress (//TODO Fix this Long term by putting an intermediate state) 2. Work gets complete and the agent returns back. We dont update the DB and send a computechecksum command to SSVM. (//TODO Long term - The create template itself should return the checksum - fix needed at ssvm for vmware and at citrix/libvrt resourcebase for XS and KVM) 3. Template sync gets triggered (because of unhealthy ssvm connecting back and forth with MS) and reports this template to the MS being on secondary storage, but we have no record that WIP in DB. So template sync deletes the template on SS. (//TODO short term - Should we be aggressive to delete the template or just sending an alert is fine ? Or if we can just relax and maybe delete in the next run or do more checking ?) 4. Compute checksum returns and DB is updated that a template is created and put into Ready status, but underlying it go deleted. For now I have changed the compute checksum logic after updating the DB that template is created. See the commit above for more information. BUT, this doesnt completely eliminate the race condition. There would still be a window where before updating the DB sync mechanism deletes the template (I think this should happen rarely), I can also make the fix possible in #3 (//TODO short term - Should we be aggressive to delete the template or just sending an alert is fine) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4833) [Automation][BVT] Template and ISO test cases failing from BVT suite, during LIST api call
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797993#comment-13797993 ] Rayees Namathponnan commented on CLOUDSTACK-4833: - This issue is only with master not 4.2.1 Have you tried with master ? [Automation][BVT] Template and ISO test cases failing from BVT suite, during LIST api call --- Key: CLOUDSTACK-4833 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4833 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: KVM automation on master Reporter: Rayees Namathponnan Assignee: Gaurav Aradhye Priority: Blocker Fix For: 4.3.0 ISO and Template test cases from master BVT suite i) test_iso.py 2) integration.smoke.test_templates.TestTemplates.test_03_delete_template Both the test cases are failed during list API call, you can see the result at http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/suite=test_templates/lastCompletedBuild/testReport/integration.smoke.test_templates/TestTemplates/test_03_delete_template/ Error Message Execute cmd: listtemplates failed, due to: errorCode: 431, errorText:Unable to execute API command listtemplates due to invalid value. Invalid parameter id value=f3abe3e3-2712-476d-9d71-05207597e4f4 due to incorrect long value format, or entity does not exist or due to incorrect parameter annotation for the field in api cmd class. begin captured logging test_03_delete_template (integration.smoke.test_templates.TestTemplates): DEBUG: Deleting Template ID: f3abe3e3-2712-476d-9d71-05207597e4f4 - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/test/integration/smoke/test_templates.py, line 543, in test_03_delete_template domainid=self.account.domainid File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/integration/lib/common.py, line 534, in list_templates return(apiclient.listTemplates(cmd)) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py, line 713, in listTemplates response = self.connection.marvin_request(command, response_type=response, method=method) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 222, in marvin_request response = jsonHelper.getResultObj(response.json(), response_type) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_templates/887/lib/python2.7/site-packages/marvin/jsonHelper.py, line 148, in getResultObj raise cloudstackException.cloudstackAPIException(respname, errMsg) Execute cmd: listtemplates failed, due to: errorCode: 431, errorText:Unable to execute API command listtemplates due to invalid value. Invalid parameter id value=f3abe3e3-2712-476d-9d71-05207597e4f4 due to incorrect long value format, or entity does not exist or due to incorrect parameter annotation for the field in api cmd class. begin captured logging test_03_delete_template (integration.smoke.test_templates.TestTemplates): DEBUG: Deleting Template ID: f3abe3e3-2712-476d-9d71-05207597e4f4 - end captured logging - and http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/suite=test_iso/lastCompletedBuild/testReport/%3Cnose/suite/ContextSuite_context_TestISO__setup/ Error Message Exception while downloading ISO b2a39aff-95c9-447a-9318-a2702eaab1cc: Execute cmd: listisos failed, due to: errorCode: 431, errorText:Unable to execute API command listisos due to invalid value. Invalid parameter id value=b2a39aff-95c9-447a-9318-a2702eaab1cc due to incorrect long value format, or entity does not exist or due to incorrect parameter annotation for the field in api cmd class. Stacktrace Traceback (most recent call last): File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_iso/887/lib/python2.7/site-packages/nose/suite.py, line 208, in run self.setUp() File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_iso/887/lib/python2.7/site-packages/nose/suite.py, line 291, in setUp self.setupContext(ancestor) File
[jira] [Commented] (CLOUDSTACK-4835) [Automation] [BVT] Update global configuration test cases failed in master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797994#comment-13797994 ] Rayees Namathponnan commented on CLOUDSTACK-4835: - Have you tried with master build ? [Automation] [BVT] Update global configuration test cases failed in master -- Key: CLOUDSTACK-4835 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4835 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: KVM Branch - master Reporter: Rayees Namathponnan Assignee: Gaurav Aradhye Priority: Blocker Fix For: 4.3.0 Below BVT test cases failed, integration.smoke.test_global_settings.TestUpdateConfigWithScope.test_UpdateConfigParamWithScope Unable to find the global property use.external.dns in master, is it removed ? you can see the result at http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/lastCompletedBuild/suite=test_global_settings/#showFailuresLink Error Message Execute cmd: updateconfiguration failed, due to: errorCode: 431, errorText:Config parameter with name use.external.dns doesn't exist Stacktrace Traceback (most recent call last): File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/test/integration/smoke/test_global_settings.py, line 47, in test_UpdateConfigParamWithScope updateConfigurationResponse = self.apiClient.updateConfiguration(updateConfigurationCmd) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py, line 1188, in updateConfiguration response = self.connection.marvin_request(command, response_type=response, method=method) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 222, in marvin_request response = jsonHelper.getResultObj(response.json(), response_type) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/jsonHelper.py, line 148, in getResultObj raise cloudstackException.cloudstackAPIException(respname, errMsg) cloudstackAPIException: Execute cmd: updateconfiguration failed, due to: errorCode: 431, errorText:Config parameter with name use.external.dns doesn't exist -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4493) registerSSHKeyPair API doc contains wrong API response (private key)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-4493: --- Fix Version/s: (was: 4.2.1) 4.3.0 registerSSHKeyPair API doc contains wrong API response (private key) Key: CLOUDSTACK-4493 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4493 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.3.0 registerSSHKeyPair API returns only name and fingerprint of the ssh keypair (sets null to private key parameter). Our API doc http://cloudstack.apache.org/docs/api/apidocs-4.1/user/registerSSHKeyPair.html has an extra parameter private key in response which anyway we return null. Response Name : Description - fingerprint : Fingerprint of the public key name : Name of the keypair privatekey: Private key This is because we use same response object for all ssh key pair related APIs. In this case it is misleading and seems like CS API leaks implementation details. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4816) provide configurable option to choose single vs multipart upload to S3 object storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798136#comment-13798136 ] ASF subversion and git services commented on CLOUDSTACK-4816: - Commit 25acfbad78d0adc4ccf798f31d685be9c068c254 in branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=25acfba ] CLOUDSTACK-4816:provide configurable option to choose single vs multipart upload to S3 object storage based on object size. provide configurable option to choose single vs multipart upload to S3 object storage -- Key: CLOUDSTACK-4816 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4816 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.2.1 In 4.2, we only supports multipart upload for registering templates and uploading volumes to object storage in secondary storage. The value of multi-part is for network failure and throughput when you are going to a remote storage. But with local storage (local to the DC) customers may prefer single upload. Also, for templates you know the full size of the object upfront and don't really need a multipart upload. Some object storage vendors may prefer that this can be configured. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4746) Allocation capacity of a cluster during HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-4746: Fix Version/s: (was: 4.3.0) 4.2.1 Allocation capacity of a cluster during HA -- Key: CLOUDSTACK-4746 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4746 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.2.1 When the host goes down. Cloudstack will stop the VM's for which HA is not enabled. Once cloudstack marks these VM's as stopped then the capacity of these VM's is moved into the reserved capacity. If the VM's are HA enabled then cloudstack will stop and start the VM's on another host. During this time the capacity of the VM's will be moved to reserved capacity once the VM's are stopped, But when the Vm's are being started cloudstack will try to calculate what will be total allocated capacity if the VM is started again ( even though the CPU for the VM is already reserved). This is a bug in cloudstack where the CPU required for the VM is considered twice when calculating the allocated capacity. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4746) Allocation capacity of a cluster during HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta reassigned CLOUDSTACK-4746: --- Assignee: Nitin Mehta (was: Prachi Damle) Allocation capacity of a cluster during HA -- Key: CLOUDSTACK-4746 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4746 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.2.1 When the host goes down. Cloudstack will stop the VM's for which HA is not enabled. Once cloudstack marks these VM's as stopped then the capacity of these VM's is moved into the reserved capacity. If the VM's are HA enabled then cloudstack will stop and start the VM's on another host. During this time the capacity of the VM's will be moved to reserved capacity once the VM's are stopped, But when the Vm's are being started cloudstack will try to calculate what will be total allocated capacity if the VM is started again ( even though the CPU for the VM is already reserved). This is a bug in cloudstack where the CPU required for the VM is considered twice when calculating the allocated capacity. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-754) nTier Apps 2.0 : Remote access VPN to VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798166#comment-13798166 ] ASF subversion and git services commented on CLOUDSTACK-754: Commit 73c7de70e971314a568ff748e6b1752a86ae1e21 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=73c7de7 ] CLOUDSTACK-754: UI add Remote Access VPN support for VPC sourceNAT IP. nTier Apps 2.0 : Remote access VPN to VPC - Key: CLOUDSTACK-754 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-754 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Reporter: Kishan Kavala Assignee: Sheng Yang Priority: Critical Fix For: 4.3.0 This item is a sub task (2.9) of https://issues.apache.org/jira/browse/CLOUDSTACK-621 This would enable remote-users to login to their VPC network -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4649) Windows Vms that were deployed in 6.0.2 Xenservers fail to start (after being stopped) after upgrading host to 6.2.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798234#comment-13798234 ] ASF subversion and git services commented on CLOUDSTACK-4649: - Commit fdd33fbb174b3279ab8ab6cde30e6185ac8da7e2 in branch refs/heads/4.2 from [~anthonyxu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fdd33fb ] Revert CLOUDSTACK-4649 This reverts commit 5950d37e9f57a41a945a11724f250aaeffa9b118. Windows Vms that were deployed in 6.0.2 Xenservers fail to start (after being stopped) after upgrading host to 6.2. --- Key: CLOUDSTACK-4649 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4649 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Environment: Build from 4.2-forward Reporter: Sangeetha Hariharan Assignee: Anthony Xu Priority: Critical Fix For: 4.2.1 Attachments: XenUpgrade.rar Windows Vms that were deployed in 6.0.2 Xenservers fail to start (after being stopped) after upgrade to 6.2 Steps to reproduce the problem: 1. Advanced zone with XS 6.0.2 2. install windows 2008 VM 3. install xs-tools(XS 6.0.2) in windows 2008 VM 4. upgrade XS 6.0.2 to XS 6.2 As part of upgrade procedure , we are able to see all the Vms successfully live migrate from XS 6.0.2 host to an upgraded XS 6.2 host. 6. Now stop and start this windows VM. Vm start reportd success. Vm does not boot successfully. We see the following exception on the screen: System Recovery Option: -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4887) CLVM broken
Marcus Sorensen created CLOUDSTACK-4887:
---
Summary: CLVM broken
Key: CLOUDSTACK-4887
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4887
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: Future
Reporter: Marcus Sorensen
Assignee: Chris Suich
Priority: Blocker
Fix For: Future
Chris,
I think commit 180cfa19 broke CLVM primary storage for KVM. I'm failing VM
deploy from template. I've been building a 'sanity check' test that focuses on
the KVM specific suff (tests storage types and supported host OS for now), and
this bubbled up.
I reverted this one part in my local code and am testing (seems to fix it), but
since I'm not clear on the refactor efforts I'm not sure what it should really
be changed to in order to meet your requirements and keep CLVM working.
@@ -65,7 +68,7 @@ public class StorageSubsystemCommandHandlerBase implements
StorageSubsystemComma
DataStoreTO srcDataStore = srcData.getDataStore();
DataStoreTO destDataStore = destData.getDataStore();
-if ((srcData.getObjectType() == DataObjectType.TEMPLATE)
(srcDataStore instanceof NfsTO) (destData.getDataStore().getRole() ==
DataStoreRole.Primary)) {
+if ((srcData.getObjectType() == DataObjectType.TEMPLATE)
(destData.getObjectType() == DataObjectType.TEMPLATE
destData.getDataStore().getRole() == DataStoreRole.Primary)) {
//copy template to primary storage
return processor.copyTemplateToPrimaryStorage(cmd);
} else if (srcData.getObjectType() == DataObjectType.TEMPLATE
srcDataStore.getRole() == DataStoreRole.Primary destDataStore.getRole() ==
DataStoreRole.Primary) {
4.2 command:
{ Cmd , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/201/fe75caa3-78fd-38ba-b34c-101d0502df2e.qcow2,origUrl:http://marcus.mlsorensen.com/cloudstack-extras/tiny-centos-63.qcow2,uuid:4795671b-dd72-4e62-9aac-c0e1d6732003,id:201,format:QCOW2,accountId:1,checksum:44cd0e6330a59f031460bc18a40c95a2,hvm:true,displayText:tiny,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://172.17.10.10:/nfs/secondary,_role:Image}},name:201-1-2b35186d-79a6-33dc-8b33-83eb650e5e1d,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:73f86d88-ccff-4dfb-ac86-2d76b7891117,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:08e8d399-b238-48f9-a497-1f7f5285d655,id:2,poolType:CLVM,host:localhost,path:vg0,port:0}},name:ROOT-6,size:1073741824,volumeId:6,vmName:i-1-6-VM,accountId:1,format:QCOW2,id:6,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
}
4.2 response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{newData:{org.apache.cloudstack.storage.to.VolumeObjectTO:{path:f69879c0-ae3b-433a-841f-f1f5afc04fc7,accountId:0,format:RAW,id:0}},result:true,wait:0}}]
}
master command:
{ Cmd , MgmtId: 52241639751, via: 1(devcloud-kvm-u), Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/4/02170718-210a-3d8c-91a2-2793ed52f1d8.qcow2,origUrl:http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2,uuid:07088e98-1fda-11e3-a1ff-000c29d82947,id:4,format:QCOW2,accountId:1,checksum:ed0e788280ff2912ea40f7f91ca7a249,hvm:false,displayText:CentOS
5.5(64-bit) no GUI
(KVM),imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://172.17.10.10:/nfs/secondary,_role:Image}},name:centos55-x86_64,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:e08f2a84-0d8b-4c6e-9593-a7554fd57b78,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:0f77072d-c76f-449c-bc6d-e2504644c0ca,id:2,poolType:CLVM,host:localhost,path:vg0,port:0}},name:ROOT-7,size:8589934592,volumeId:7,vmName:i-1-7-VM,accountId:1,format:QCOW2,id:7,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
}
master response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{com.cloud.agent.api.Answer:{result:false,details:not implemented
yet,wait:0}}] }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4887) CLVM broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798275#comment-13798275
]
Chris Suich commented on CLOUDSTACK-4887:
-
This was introduced by a bug in the storage subsystem refactoring. The posted
review can be found here: https://reviews.apache.org/r/14715/
CLVM broken
---
Key: CLOUDSTACK-4887
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4887
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: Future
Reporter: Marcus Sorensen
Assignee: Chris Suich
Priority: Blocker
Fix For: Future
Chris,
I think commit 180cfa19 broke CLVM primary storage for KVM. I'm failing VM
deploy from template. I've been building a 'sanity check' test that focuses
on the KVM specific suff (tests storage types and supported host OS for now),
and this bubbled up.
I reverted this one part in my local code and am testing (seems to fix it),
but since I'm not clear on the refactor efforts I'm not sure what it should
really be changed to in order to meet your requirements and keep CLVM working.
@@ -65,7 +68,7 @@ public class StorageSubsystemCommandHandlerBase implements
StorageSubsystemComma
DataStoreTO srcDataStore = srcData.getDataStore();
DataStoreTO destDataStore = destData.getDataStore();
-if ((srcData.getObjectType() == DataObjectType.TEMPLATE)
(srcDataStore instanceof NfsTO) (destData.getDataStore().getRole() ==
DataStoreRole.Primary)) {
+if ((srcData.getObjectType() == DataObjectType.TEMPLATE)
(destData.getObjectType() == DataObjectType.TEMPLATE
destData.getDataStore().getRole() == DataStoreRole.Primary)) {
//copy template to primary storage
return processor.copyTemplateToPrimaryStorage(cmd);
} else if (srcData.getObjectType() == DataObjectType.TEMPLATE
srcDataStore.getRole() == DataStoreRole.Primary destDataStore.getRole() ==
DataStoreRole.Primary) {
4.2 command:
{ Cmd , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/201/fe75caa3-78fd-38ba-b34c-101d0502df2e.qcow2,origUrl:http://marcus.mlsorensen.com/cloudstack-extras/tiny-centos-63.qcow2,uuid:4795671b-dd72-4e62-9aac-c0e1d6732003,id:201,format:QCOW2,accountId:1,checksum:44cd0e6330a59f031460bc18a40c95a2,hvm:true,displayText:tiny,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://172.17.10.10:/nfs/secondary,_role:Image}},name:201-1-2b35186d-79a6-33dc-8b33-83eb650e5e1d,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:73f86d88-ccff-4dfb-ac86-2d76b7891117,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:08e8d399-b238-48f9-a497-1f7f5285d655,id:2,poolType:CLVM,host:localhost,path:vg0,port:0}},name:ROOT-6,size:1073741824,volumeId:6,vmName:i-1-6-VM,accountId:1,format:QCOW2,id:6,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
}
4.2 response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{newData:{org.apache.cloudstack.storage.to.VolumeObjectTO:{path:f69879c0-ae3b-433a-841f-f1f5afc04fc7,accountId:0,format:RAW,id:0}},result:true,wait:0}}]
}
master command:
{ Cmd , MgmtId: 52241639751, via: 1(devcloud-kvm-u), Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/4/02170718-210a-3d8c-91a2-2793ed52f1d8.qcow2,origUrl:http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2,uuid:07088e98-1fda-11e3-a1ff-000c29d82947,id:4,format:QCOW2,accountId:1,checksum:ed0e788280ff2912ea40f7f91ca7a249,hvm:false,displayText:CentOS
5.5(64-bit) no GUI
(KVM),imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://172.17.10.10:/nfs/secondary,_role:Image}},name:centos55-x86_64,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:e08f2a84-0d8b-4c6e-9593-a7554fd57b78,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:0f77072d-c76f-449c-bc6d-e2504644c0ca,id:2,poolType:CLVM,host:localhost,path:vg0,port:0}},name:ROOT-7,size:8589934592,volumeId:7,vmName:i-1-7-VM,accountId:1,format:QCOW2,id:7,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
}
master response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{com.cloud.agent.api.Answer:{result:false,details:not implemented
yet,wait:0}}] }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4887) CLVM broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Suich updated CLOUDSTACK-4887:
Status: Ready To Review (was: In Progress)
CLVM broken
---
Key: CLOUDSTACK-4887
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4887
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: Future
Reporter: Marcus Sorensen
Assignee: Chris Suich
Priority: Blocker
Fix For: Future
Chris,
I think commit 180cfa19 broke CLVM primary storage for KVM. I'm failing VM
deploy from template. I've been building a 'sanity check' test that focuses
on the KVM specific suff (tests storage types and supported host OS for now),
and this bubbled up.
I reverted this one part in my local code and am testing (seems to fix it),
but since I'm not clear on the refactor efforts I'm not sure what it should
really be changed to in order to meet your requirements and keep CLVM working.
@@ -65,7 +68,7 @@ public class StorageSubsystemCommandHandlerBase implements
StorageSubsystemComma
DataStoreTO srcDataStore = srcData.getDataStore();
DataStoreTO destDataStore = destData.getDataStore();
-if ((srcData.getObjectType() == DataObjectType.TEMPLATE)
(srcDataStore instanceof NfsTO) (destData.getDataStore().getRole() ==
DataStoreRole.Primary)) {
+if ((srcData.getObjectType() == DataObjectType.TEMPLATE)
(destData.getObjectType() == DataObjectType.TEMPLATE
destData.getDataStore().getRole() == DataStoreRole.Primary)) {
//copy template to primary storage
return processor.copyTemplateToPrimaryStorage(cmd);
} else if (srcData.getObjectType() == DataObjectType.TEMPLATE
srcDataStore.getRole() == DataStoreRole.Primary destDataStore.getRole() ==
DataStoreRole.Primary) {
4.2 command:
{ Cmd , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/201/fe75caa3-78fd-38ba-b34c-101d0502df2e.qcow2,origUrl:http://marcus.mlsorensen.com/cloudstack-extras/tiny-centos-63.qcow2,uuid:4795671b-dd72-4e62-9aac-c0e1d6732003,id:201,format:QCOW2,accountId:1,checksum:44cd0e6330a59f031460bc18a40c95a2,hvm:true,displayText:tiny,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://172.17.10.10:/nfs/secondary,_role:Image}},name:201-1-2b35186d-79a6-33dc-8b33-83eb650e5e1d,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:73f86d88-ccff-4dfb-ac86-2d76b7891117,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:08e8d399-b238-48f9-a497-1f7f5285d655,id:2,poolType:CLVM,host:localhost,path:vg0,port:0}},name:ROOT-6,size:1073741824,volumeId:6,vmName:i-1-6-VM,accountId:1,format:QCOW2,id:6,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
}
4.2 response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{newData:{org.apache.cloudstack.storage.to.VolumeObjectTO:{path:f69879c0-ae3b-433a-841f-f1f5afc04fc7,accountId:0,format:RAW,id:0}},result:true,wait:0}}]
}
master command:
{ Cmd , MgmtId: 52241639751, via: 1(devcloud-kvm-u), Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/4/02170718-210a-3d8c-91a2-2793ed52f1d8.qcow2,origUrl:http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2,uuid:07088e98-1fda-11e3-a1ff-000c29d82947,id:4,format:QCOW2,accountId:1,checksum:ed0e788280ff2912ea40f7f91ca7a249,hvm:false,displayText:CentOS
5.5(64-bit) no GUI
(KVM),imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://172.17.10.10:/nfs/secondary,_role:Image}},name:centos55-x86_64,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:e08f2a84-0d8b-4c6e-9593-a7554fd57b78,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:0f77072d-c76f-449c-bc6d-e2504644c0ca,id:2,poolType:CLVM,host:localhost,path:vg0,port:0}},name:ROOT-7,size:8589934592,volumeId:7,vmName:i-1-7-VM,accountId:1,format:QCOW2,id:7,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
}
master response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{com.cloud.agent.api.Answer:{result:false,details:not implemented
yet,wait:0}}] }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber reassigned CLOUDSTACK-4792: Assignee: Milamber (was: Anshul Gangwar) Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Milamber Priority: Critical Fix For: 4.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798316#comment-13798316 ] Milamber commented on CLOUDSTACK-4792: -- Need to add some properties to javamail in the file /cloud-server/src/com/cloud/alert/AlertManagerImpl.java props.put(mail.smtp.connectiontimeout,2); props.put(mail.smtp.timeout,2); props.put(mail.smtps.connectiontimeout,2); props.put(mail.smtps.timeout,2); I will works to add these properties in CS Global Properties Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4888) API:UCS:NPE Refresh blades on a decommissioned chassis results in NPE
Parth Jagirdar created CLOUDSTACK-4888: -- Summary: API:UCS:NPE Refresh blades on a decommissioned chassis results in NPE Key: CLOUDSTACK-4888 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4888 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, UCS Affects Versions: 4.2.0 Environment: UCS Reporter: Parth Jagirdar Priority: Critical Fix For: 4.2.1 Expecting an appropriate error. When refresh blades is issues on a decommissioned chassis. 2013-10-17 13:52:26,432 DEBUG [cloud.api.ApiServlet] (catalina-exec-6:null) ===START=== 10.215.2.19 -- GET command=refreshUcsBladesresponse=jsonsessionkey=e0Kgb2hcBQPMXSe5O%2FDeRH8v2%2B8%3Ducsmanagerid=f185ae78-08cb-4a06-a3c8-47c3d2afa896_=1382043146927 2013-10-17 13:52:26,451 DEBUG [ucs.manager.UcsHttpClient] (catalina-exec-6:null) UCS call: configResolveClass cookie=1382042998/2e94d89b-026b-4fbd-be82-489759483570 inHierarchical=false classId=computeBlade / 2013-10-17 13:52:26,458 WARN [ucs.manager.UcsManagerImpl] (catalina-exec-6:null) null java.lang.NullPointerException at com.cloud.ucs.structure.ComputeBlade.fromXmlObject(ComputeBlade.java:62) at com.cloud.ucs.structure.ComputeBlade.fromXmString(ComputeBlade.java:55) at com.cloud.ucs.manager.UcsManagerImpl.listBlades(UcsManagerImpl.java:285) at com.cloud.ucs.manager.UcsManagerImpl.access$100(UcsManagerImpl.java:65) at com.cloud.ucs.manager.UcsManagerImpl$SyncBladesThread.syncBlades(UcsManagerImpl.java:141) at com.cloud.ucs.manager.UcsManagerImpl$SyncBladesThread.run(UcsManagerImpl.java:156) at com.cloud.ucs.manager.UcsManagerImpl.refreshBlades(UcsManagerImpl.java:624) at org.apache.cloudstack.api.RefreshUcsBladesCmd.execute(RefreshUcsBladesCmd.java:42) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2274) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) 2013-10-17 13:52:26,468 DEBUG [ucs.manager.UcsHttpClient] (catalina-exec-6:null) UCS call: configResolveClass cookie=1382042998/2e94d89b-026b-4fbd-be82-489759483570 inHierarchical=false classId=computeBlade / 2013-10-17 13:52:26,471 WARN [cloudstack.api.RefreshUcsBladesCmd] (catalina-exec-6:null) unhandled exception: java.lang.NullPointerException at com.cloud.ucs.structure.ComputeBlade.fromXmlObject(ComputeBlade.java:62) at com.cloud.ucs.structure.ComputeBlade.fromXmString(ComputeBlade.java:55) at com.cloud.ucs.manager.UcsManagerImpl.listBlades(UcsManagerImpl.java:285) at com.cloud.ucs.manager.UcsManagerImpl.refreshBlades(UcsManagerImpl.java:627) at org.apache.cloudstack.api.RefreshUcsBladesCmd.execute(RefreshUcsBladesCmd.java:42) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) at
[jira] [Assigned] (CLOUDSTACK-4889) Hide search box in UCS Blades tab since listUcsBlades API doesn't support search
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-4889: Assignee: Jessica Wang Hide search box in UCS Blades tab since listUcsBlades API doesn't support search Key: CLOUDSTACK-4889 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4889 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Jessica Wang Assignee: Jessica Wang Fix For: 4.2.1 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4889) Hide search box in UCS Blades tab since listUcsBlades API doesn't support search
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798525#comment-13798525 ] ASF subversion and git services commented on CLOUDSTACK-4889: - Commit 7ef4c7e1a47fca9ac78e5391638782cd29a6188e in branch refs/heads/4.2 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7ef4c7e ] CLOUDSTACK-4889: UI (1) extend listView widget to support option of hiding/showing search box. (2) Hide search box in UCS Blades tab. Hide search box in UCS Blades tab since listUcsBlades API doesn't support search Key: CLOUDSTACK-4889 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4889 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Jessica Wang Assignee: Jessica Wang Fix For: 4.2.1 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4889) Hide search box in UCS Blades tab since listUcsBlades API doesn't support search
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-4889: - Fix Version/s: 4.2.1 Hide search box in UCS Blades tab since listUcsBlades API doesn't support search Key: CLOUDSTACK-4889 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4889 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Jessica Wang Assignee: Jessica Wang Fix For: 4.2.1 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4889) Hide search box in UCS Blades tab since listUcsBlades API doesn't support search
Jessica Wang created CLOUDSTACK-4889: Summary: Hide search box in UCS Blades tab since listUcsBlades API doesn't support search Key: CLOUDSTACK-4889 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4889 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Jessica Wang -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4889) Hide search box in UCS Blades tab since listUcsBlades API doesn't support search
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798529#comment-13798529 ] ASF subversion and git services commented on CLOUDSTACK-4889: - Commit 12189074b2e39a99b7021fdb19286a45b6150d18 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1218907 ] CLOUDSTACK-4889: UI (1) extend listView widget to support option of hiding/showing search box. (2) Hide search box in UCS Blades tab. Hide search box in UCS Blades tab since listUcsBlades API doesn't support search Key: CLOUDSTACK-4889 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4889 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Jessica Wang Assignee: Jessica Wang Fix For: 4.2.1 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4889) Hide search box in UCS Blades tab since listUcsBlades API doesn't support search
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-4889. -- Resolution: Fixed Hide search box in UCS Blades tab since listUcsBlades API doesn't support search Key: CLOUDSTACK-4889 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4889 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Jessica Wang Assignee: Jessica Wang Fix For: 4.2.1 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3472) [Object_Store_Refactor] System VMs are not coming up in initial attempt, but they are coming up after multiple attempts
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798561#comment-13798561
]
ASF subversion and git services commented on CLOUDSTACK-3472:
-
Commit ec3302afd6c1676f766b6e731c101eaf316cd7cf in branch refs/heads/master
from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ec3302a ]
CLOUDSTACK-3472: [Object_Store_Refactor] System VMs are not coming up in
initial attempt, but they are coming up after multiple attempts.
[Object_Store_Refactor] System VMs are not coming up in initial attempt, but
they are coming up after multiple attempts
---
Key: CLOUDSTACK-3472
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3472
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Install and Setup
Affects Versions: 4.2.0
Environment: Latest build from ACS4.2 branch:
Cluster:XenServer6.1
Reporter: Sanjeev N
Assignee: Min Chen
Priority: Critical
Fix For: 4.2.0
Attachments: management-server.rar
System VMs are not coming up in initial attempt, but they are coming up after
multiple attempts.
Failed to create VDI in SR initially but succeeding after several failed
attempts.
Copycommand is failing with Runtime exception:
2013-07-11 11:25:17,554 DEBUG [agent.transport.Request] (DirectAgent-73:null)
Seq 1-557449293: Processing: { Ans: , MgmtId: 6615759585382, via: 1, Ver:
v1, Flags: 110,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{result:false,details:Catch
Exception com.cloud.utils.exception.CloudRuntimeException for template +
due to com.cloud.utils.exception.CloudRuntimeException: can not create vdi in
sr f3429124-745a-70d1-da86-ce97bfb2570d,wait:0}}] }
sr-list on hypervisor:
[root@Rack1Pod1Host13 ~]# xe sr-list type=nfs
uuid ( RO): f3429124-745a-70d1-da86-ce97bfb2570d
name-label ( RW): c65a038a-750c-3b4f-bf26-7ce3b74e1c85
name-description ( RW): 1
host ( RO): Rack1Pod1Host13
type ( RO): nfs
content-type ( RO): user
Log snippet from management server log:
2013-07-11 11:25:15,239 DEBUG [agent.transport.Request] (DirectAgent-15:null)
Seq 1-557449293: Executing: { Cmd , MgmtId: 6615759585382, via: 1, Ver: v1,
Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/1/ddc39e82-13b4-4d30-9149-5ea6c1b801d5.vhd,origUrl:http://10.147.28.7/templates/newsysvmtemp/systemvmtemplate-2013-06-23-master-xen.vhd.bz2,uuid:39355f04-ea28-11e2-9610-06045a66,id:1,format:VHD,accountId:1,checksum:7d76f106e5a5f6b68d114291c5938b41,hvm:false,displayText:SystemVM
Template
(XenServer),imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.147.28.7/export/home/sanjeev/sec_xen_os,_role:ImageCache}},name:routing-1}},destTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{origUrl:http://10.147.28.7/templates/newsysvmtemp/systemvmtemplate-2013-06-23-master-xen.vhd.bz2,uuid:39355f04-ea28-11e2-9610-06045a66,id:1,format:VHD,accountId:1,checksum:7d76f106e5a5f6b68d114291c5938b41,hvm:false,displayText:SystemVM
Template
(XenServer),imageDataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:c65a038a-750c-3b4f-bf26-7ce3b74e1c85,id:1,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/sanjeev/pri_xen_os,port:2049}},name:routing-1}},wait:10800}}]
}
2013-07-11 11:25:15,241 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-73:null) Seq 1-557449293: Executing request
2013-07-11 11:25:16,175 DEBUG [agent.transport.Request] (secstorage-1:null)
Seq 1-557449302: Waiting for Seq 557449293 Scheduling: { Cmd , MgmtId:
6615759585382, via: 1, Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:5b6d5297-e270-4d01-ad4c-f5a75d96134c,origUrl:http://10.147.28.7/templates/newsysvmtemp/systemvmtemplate-2013-06-23-master-xen.vhd.bz2,uuid:39355f04-ea28-11e2-9610-06045a66,id:1,format:VHD,accountId:1,checksum:7d76f106e5a5f6b68d114291c5938b41,hvm:false,displayText:SystemVM
Template
[jira] [Resolved] (CLOUDSTACK-4887) CLVM broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Sorensen resolved CLOUDSTACK-4887.
-
Resolution: Fixed
CLVM broken
---
Key: CLOUDSTACK-4887
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4887
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: Future
Reporter: Marcus Sorensen
Assignee: Marcus Sorensen
Priority: Blocker
Fix For: Future
Chris,
I think commit 180cfa19 broke CLVM primary storage for KVM. I'm failing VM
deploy from template. I've been building a 'sanity check' test that focuses
on the KVM specific suff (tests storage types and supported host OS for now),
and this bubbled up.
I reverted this one part in my local code and am testing (seems to fix it),
but since I'm not clear on the refactor efforts I'm not sure what it should
really be changed to in order to meet your requirements and keep CLVM working.
@@ -65,7 +68,7 @@ public class StorageSubsystemCommandHandlerBase implements
StorageSubsystemComma
DataStoreTO srcDataStore = srcData.getDataStore();
DataStoreTO destDataStore = destData.getDataStore();
-if ((srcData.getObjectType() == DataObjectType.TEMPLATE)
(srcDataStore instanceof NfsTO) (destData.getDataStore().getRole() ==
DataStoreRole.Primary)) {
+if ((srcData.getObjectType() == DataObjectType.TEMPLATE)
(destData.getObjectType() == DataObjectType.TEMPLATE
destData.getDataStore().getRole() == DataStoreRole.Primary)) {
//copy template to primary storage
return processor.copyTemplateToPrimaryStorage(cmd);
} else if (srcData.getObjectType() == DataObjectType.TEMPLATE
srcDataStore.getRole() == DataStoreRole.Primary destDataStore.getRole() ==
DataStoreRole.Primary) {
4.2 command:
{ Cmd , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/201/fe75caa3-78fd-38ba-b34c-101d0502df2e.qcow2,origUrl:http://marcus.mlsorensen.com/cloudstack-extras/tiny-centos-63.qcow2,uuid:4795671b-dd72-4e62-9aac-c0e1d6732003,id:201,format:QCOW2,accountId:1,checksum:44cd0e6330a59f031460bc18a40c95a2,hvm:true,displayText:tiny,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://172.17.10.10:/nfs/secondary,_role:Image}},name:201-1-2b35186d-79a6-33dc-8b33-83eb650e5e1d,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:73f86d88-ccff-4dfb-ac86-2d76b7891117,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:08e8d399-b238-48f9-a497-1f7f5285d655,id:2,poolType:CLVM,host:localhost,path:vg0,port:0}},name:ROOT-6,size:1073741824,volumeId:6,vmName:i-1-6-VM,accountId:1,format:QCOW2,id:6,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
}
4.2 response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{newData:{org.apache.cloudstack.storage.to.VolumeObjectTO:{path:f69879c0-ae3b-433a-841f-f1f5afc04fc7,accountId:0,format:RAW,id:0}},result:true,wait:0}}]
}
master command:
{ Cmd , MgmtId: 52241639751, via: 1(devcloud-kvm-u), Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/4/02170718-210a-3d8c-91a2-2793ed52f1d8.qcow2,origUrl:http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2,uuid:07088e98-1fda-11e3-a1ff-000c29d82947,id:4,format:QCOW2,accountId:1,checksum:ed0e788280ff2912ea40f7f91ca7a249,hvm:false,displayText:CentOS
5.5(64-bit) no GUI
(KVM),imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://172.17.10.10:/nfs/secondary,_role:Image}},name:centos55-x86_64,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:e08f2a84-0d8b-4c6e-9593-a7554fd57b78,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:0f77072d-c76f-449c-bc6d-e2504644c0ca,id:2,poolType:CLVM,host:localhost,path:vg0,port:0}},name:ROOT-7,size:8589934592,volumeId:7,vmName:i-1-7-VM,accountId:1,format:QCOW2,id:7,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
}
master response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{com.cloud.agent.api.Answer:{result:false,details:not implemented
yet,wait:0}}] }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4887) CLVM broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798622#comment-13798622
]
ASF subversion and git services commented on CLOUDSTACK-4887:
-
Commit a504c004bf10555e5ea67ec89fe7bf6f00fe4622 in branch refs/heads/master
from [~mlsorensen]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a504c00 ]
CLOUDSTACK-4887: Fix CLVM template download from storage refactoring work
CLVM broken
---
Key: CLOUDSTACK-4887
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4887
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: Future
Reporter: Marcus Sorensen
Assignee: Chris Suich
Priority: Blocker
Fix For: Future
Chris,
I think commit 180cfa19 broke CLVM primary storage for KVM. I'm failing VM
deploy from template. I've been building a 'sanity check' test that focuses
on the KVM specific suff (tests storage types and supported host OS for now),
and this bubbled up.
I reverted this one part in my local code and am testing (seems to fix it),
but since I'm not clear on the refactor efforts I'm not sure what it should
really be changed to in order to meet your requirements and keep CLVM working.
@@ -65,7 +68,7 @@ public class StorageSubsystemCommandHandlerBase implements
StorageSubsystemComma
DataStoreTO srcDataStore = srcData.getDataStore();
DataStoreTO destDataStore = destData.getDataStore();
-if ((srcData.getObjectType() == DataObjectType.TEMPLATE)
(srcDataStore instanceof NfsTO) (destData.getDataStore().getRole() ==
DataStoreRole.Primary)) {
+if ((srcData.getObjectType() == DataObjectType.TEMPLATE)
(destData.getObjectType() == DataObjectType.TEMPLATE
destData.getDataStore().getRole() == DataStoreRole.Primary)) {
//copy template to primary storage
return processor.copyTemplateToPrimaryStorage(cmd);
} else if (srcData.getObjectType() == DataObjectType.TEMPLATE
srcDataStore.getRole() == DataStoreRole.Primary destDataStore.getRole() ==
DataStoreRole.Primary) {
4.2 command:
{ Cmd , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/201/fe75caa3-78fd-38ba-b34c-101d0502df2e.qcow2,origUrl:http://marcus.mlsorensen.com/cloudstack-extras/tiny-centos-63.qcow2,uuid:4795671b-dd72-4e62-9aac-c0e1d6732003,id:201,format:QCOW2,accountId:1,checksum:44cd0e6330a59f031460bc18a40c95a2,hvm:true,displayText:tiny,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://172.17.10.10:/nfs/secondary,_role:Image}},name:201-1-2b35186d-79a6-33dc-8b33-83eb650e5e1d,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:73f86d88-ccff-4dfb-ac86-2d76b7891117,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:08e8d399-b238-48f9-a497-1f7f5285d655,id:2,poolType:CLVM,host:localhost,path:vg0,port:0}},name:ROOT-6,size:1073741824,volumeId:6,vmName:i-1-6-VM,accountId:1,format:QCOW2,id:6,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
}
4.2 response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{newData:{org.apache.cloudstack.storage.to.VolumeObjectTO:{path:f69879c0-ae3b-433a-841f-f1f5afc04fc7,accountId:0,format:RAW,id:0}},result:true,wait:0}}]
}
master command:
{ Cmd , MgmtId: 52241639751, via: 1(devcloud-kvm-u), Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/4/02170718-210a-3d8c-91a2-2793ed52f1d8.qcow2,origUrl:http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2,uuid:07088e98-1fda-11e3-a1ff-000c29d82947,id:4,format:QCOW2,accountId:1,checksum:ed0e788280ff2912ea40f7f91ca7a249,hvm:false,displayText:CentOS
5.5(64-bit) no GUI
(KVM),imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://172.17.10.10:/nfs/secondary,_role:Image}},name:centos55-x86_64,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:e08f2a84-0d8b-4c6e-9593-a7554fd57b78,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:0f77072d-c76f-449c-bc6d-e2504644c0ca,id:2,poolType:CLVM,host:localhost,path:vg0,port:0}},name:ROOT-7,size:8589934592,volumeId:7,vmName:i-1-7-VM,accountId:1,format:QCOW2,id:7,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
}
master response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{com.cloud.agent.api.Answer:{result:false,details:not
[jira] [Closed] (CLOUDSTACK-4887) CLVM broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Sorensen closed CLOUDSTACK-4887.
---
CLVM broken
---
Key: CLOUDSTACK-4887
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4887
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: Future
Reporter: Marcus Sorensen
Assignee: Marcus Sorensen
Priority: Blocker
Fix For: Future
Chris,
I think commit 180cfa19 broke CLVM primary storage for KVM. I'm failing VM
deploy from template. I've been building a 'sanity check' test that focuses
on the KVM specific suff (tests storage types and supported host OS for now),
and this bubbled up.
I reverted this one part in my local code and am testing (seems to fix it),
but since I'm not clear on the refactor efforts I'm not sure what it should
really be changed to in order to meet your requirements and keep CLVM working.
@@ -65,7 +68,7 @@ public class StorageSubsystemCommandHandlerBase implements
StorageSubsystemComma
DataStoreTO srcDataStore = srcData.getDataStore();
DataStoreTO destDataStore = destData.getDataStore();
-if ((srcData.getObjectType() == DataObjectType.TEMPLATE)
(srcDataStore instanceof NfsTO) (destData.getDataStore().getRole() ==
DataStoreRole.Primary)) {
+if ((srcData.getObjectType() == DataObjectType.TEMPLATE)
(destData.getObjectType() == DataObjectType.TEMPLATE
destData.getDataStore().getRole() == DataStoreRole.Primary)) {
//copy template to primary storage
return processor.copyTemplateToPrimaryStorage(cmd);
} else if (srcData.getObjectType() == DataObjectType.TEMPLATE
srcDataStore.getRole() == DataStoreRole.Primary destDataStore.getRole() ==
DataStoreRole.Primary) {
4.2 command:
{ Cmd , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/201/fe75caa3-78fd-38ba-b34c-101d0502df2e.qcow2,origUrl:http://marcus.mlsorensen.com/cloudstack-extras/tiny-centos-63.qcow2,uuid:4795671b-dd72-4e62-9aac-c0e1d6732003,id:201,format:QCOW2,accountId:1,checksum:44cd0e6330a59f031460bc18a40c95a2,hvm:true,displayText:tiny,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://172.17.10.10:/nfs/secondary,_role:Image}},name:201-1-2b35186d-79a6-33dc-8b33-83eb650e5e1d,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:73f86d88-ccff-4dfb-ac86-2d76b7891117,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:08e8d399-b238-48f9-a497-1f7f5285d655,id:2,poolType:CLVM,host:localhost,path:vg0,port:0}},name:ROOT-6,size:1073741824,volumeId:6,vmName:i-1-6-VM,accountId:1,format:QCOW2,id:6,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
}
4.2 response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{newData:{org.apache.cloudstack.storage.to.VolumeObjectTO:{path:f69879c0-ae3b-433a-841f-f1f5afc04fc7,accountId:0,format:RAW,id:0}},result:true,wait:0}}]
}
master command:
{ Cmd , MgmtId: 52241639751, via: 1(devcloud-kvm-u), Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/4/02170718-210a-3d8c-91a2-2793ed52f1d8.qcow2,origUrl:http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2,uuid:07088e98-1fda-11e3-a1ff-000c29d82947,id:4,format:QCOW2,accountId:1,checksum:ed0e788280ff2912ea40f7f91ca7a249,hvm:false,displayText:CentOS
5.5(64-bit) no GUI
(KVM),imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://172.17.10.10:/nfs/secondary,_role:Image}},name:centos55-x86_64,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:e08f2a84-0d8b-4c6e-9593-a7554fd57b78,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:0f77072d-c76f-449c-bc6d-e2504644c0ca,id:2,poolType:CLVM,host:localhost,path:vg0,port:0}},name:ROOT-7,size:8589934592,volumeId:7,vmName:i-1-7-VM,accountId:1,format:QCOW2,id:7,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
}
master response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{com.cloud.agent.api.Answer:{result:false,details:not implemented
yet,wait:0}}] }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4887) CLVM broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Sorensen reassigned CLOUDSTACK-4887:
---
Assignee: Marcus Sorensen (was: Chris Suich)
CLVM broken
---
Key: CLOUDSTACK-4887
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4887
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: Future
Reporter: Marcus Sorensen
Assignee: Marcus Sorensen
Priority: Blocker
Fix For: Future
Chris,
I think commit 180cfa19 broke CLVM primary storage for KVM. I'm failing VM
deploy from template. I've been building a 'sanity check' test that focuses
on the KVM specific suff (tests storage types and supported host OS for now),
and this bubbled up.
I reverted this one part in my local code and am testing (seems to fix it),
but since I'm not clear on the refactor efforts I'm not sure what it should
really be changed to in order to meet your requirements and keep CLVM working.
@@ -65,7 +68,7 @@ public class StorageSubsystemCommandHandlerBase implements
StorageSubsystemComma
DataStoreTO srcDataStore = srcData.getDataStore();
DataStoreTO destDataStore = destData.getDataStore();
-if ((srcData.getObjectType() == DataObjectType.TEMPLATE)
(srcDataStore instanceof NfsTO) (destData.getDataStore().getRole() ==
DataStoreRole.Primary)) {
+if ((srcData.getObjectType() == DataObjectType.TEMPLATE)
(destData.getObjectType() == DataObjectType.TEMPLATE
destData.getDataStore().getRole() == DataStoreRole.Primary)) {
//copy template to primary storage
return processor.copyTemplateToPrimaryStorage(cmd);
} else if (srcData.getObjectType() == DataObjectType.TEMPLATE
srcDataStore.getRole() == DataStoreRole.Primary destDataStore.getRole() ==
DataStoreRole.Primary) {
4.2 command:
{ Cmd , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/201/fe75caa3-78fd-38ba-b34c-101d0502df2e.qcow2,origUrl:http://marcus.mlsorensen.com/cloudstack-extras/tiny-centos-63.qcow2,uuid:4795671b-dd72-4e62-9aac-c0e1d6732003,id:201,format:QCOW2,accountId:1,checksum:44cd0e6330a59f031460bc18a40c95a2,hvm:true,displayText:tiny,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://172.17.10.10:/nfs/secondary,_role:Image}},name:201-1-2b35186d-79a6-33dc-8b33-83eb650e5e1d,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:73f86d88-ccff-4dfb-ac86-2d76b7891117,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:08e8d399-b238-48f9-a497-1f7f5285d655,id:2,poolType:CLVM,host:localhost,path:vg0,port:0}},name:ROOT-6,size:1073741824,volumeId:6,vmName:i-1-6-VM,accountId:1,format:QCOW2,id:6,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
}
4.2 response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{newData:{org.apache.cloudstack.storage.to.VolumeObjectTO:{path:f69879c0-ae3b-433a-841f-f1f5afc04fc7,accountId:0,format:RAW,id:0}},result:true,wait:0}}]
}
master command:
{ Cmd , MgmtId: 52241639751, via: 1(devcloud-kvm-u), Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/4/02170718-210a-3d8c-91a2-2793ed52f1d8.qcow2,origUrl:http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2,uuid:07088e98-1fda-11e3-a1ff-000c29d82947,id:4,format:QCOW2,accountId:1,checksum:ed0e788280ff2912ea40f7f91ca7a249,hvm:false,displayText:CentOS
5.5(64-bit) no GUI
(KVM),imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://172.17.10.10:/nfs/secondary,_role:Image}},name:centos55-x86_64,hypervisorType:KVM}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:e08f2a84-0d8b-4c6e-9593-a7554fd57b78,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:0f77072d-c76f-449c-bc6d-e2504644c0ca,id:2,poolType:CLVM,host:localhost,path:vg0,port:0}},name:ROOT-7,size:8589934592,volumeId:7,vmName:i-1-7-VM,accountId:1,format:QCOW2,id:7,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
}
master response:
{ Ans: , MgmtId: 52241639751, via: 1, Ver: v1, Flags: 110,
[{com.cloud.agent.api.Answer:{result:false,details:not implemented
yet,wait:0}}] }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4637) [Automation] test_egress_fw_rules.py fails with Script result is ['send: spawn id exp3 not open' ....'] is not matching with ['100'] in KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798625#comment-13798625 ] ASF subversion and git services commented on CLOUDSTACK-4637: - Commit a65f1ebefca7b22512762faf1832291153782f58 in branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a65f1eb ] CLOUDSTACK-4637: Fix failures in test_egress_fw_rules.py Removed log_test_exceptions which did not add any value. Skipped few tests which are incomplete. Added timeout logic and to wait for router to boot. [Automation] test_egress_fw_rules.py fails with Script result is ['send: spawn id exp3 not open' '] is not matching with ['100'] in KVM --- Key: CLOUDSTACK-4637 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4637 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Reporter: Girish Shilamkar Assignee: Girish Shilamkar Priority: Critical Still fails Script result is ['send: spawn id exp3 not open', ' while executing', 'send ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=quiet root@10.1.1.183 ping -c 1 www.google.com; exit $?', '', ' (file /tmp/expect_script.exp line 4)'] is not matching with ['100'] begin captured logging testclient.testcase.TestEgressFWRules: DEBUG: Creating network with network offering: 05d985b1-ee1c-4b04-9cee-d6c97e43032d testclient.testcase.TestEgressFWRules: DEBUG: Created network with ID: 02187a7a-9afe-45ff-b9c3-069b00c731fc testclient.testcase.TestEgressFWRules: DEBUG: Deploying instance in the account: test-B0F0Z8 testclient.testcase.TestEgressFWRules: DEBUG: Deployed instance in account: test-B0F0Z8 testclient.testcase.TestEgressFWRules: DEBUG: Creating Egress FW rule for networkid=02187a7a-9afe-45ff-b9c3-069b00c731fc networkname=Test Network testclient.testcase.TestEgressFWRules: DEBUG: Created rule=fe84b110-8042-47d3-8b72-917607ab8811 testclient.testcase.TestEgressFWRules: DEBUG: expect_script #!/usr/bin/expect spawn ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=quiet -i /root/.ssh/id_rsa.cloud -p 3922 root@169.254.2.102 expect root@r-588-QA:~# send ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=quiet root@10.1.1.183 ping -c 1 www.google.com; exit $? expect root@10.1.1.183's password: send password interact expect_script paramiko.transport: DEBUG: starting thread (client mode): 0x204143d0L paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_5.3) paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha256', 'diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256', 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijndael-...@lysator.liu.se'] server encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256', 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijndael-...@lysator.liu.se'] client mac:['hmac-md5', 'hmac-sha1', 'umac...@openssh.com', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'umac...@openssh.com', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client compress:['none', 'z...@openssh.com'] server compress:['none', 'z...@openssh.com'] client lang:[''] server lang:[''] kex follows?False paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none paramiko.transport: DEBUG: Switch to new keys ... paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.223.50.66: 41aef5f507e1ddd99077b11f4bf26553 paramiko.transport: DEBUG: Trying discovered key 76be480fa6b8ad3b78082d6d19e4ee44 in /root/.ssh/id_rsa paramiko.transport: DEBUG: userauth is OK paramiko.transport: INFO: Authentication (publickey) failed. paramiko.transport: DEBUG: userauth is OK paramiko.transport: INFO: Authentication (password) successful! sshClient: DEBUG: SSH connect: root@10.223.50.66 with passwd password testclient.testcase.TestEgressFWRules:
[jira] [Commented] (CLOUDSTACK-4637) [Automation] test_egress_fw_rules.py fails with Script result is ['send: spawn id exp3 not open' ....'] is not matching with ['100'] in KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798627#comment-13798627 ] ASF subversion and git services commented on CLOUDSTACK-4637: - Commit 833229c416cfee3e3dec3762d2e9c8e734696f90 in branch refs/heads/4.2 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=833229c ] CLOUDSTACK-4637: Fix failures in test_egress_fw_rules.py Removed log_test_exceptions which did not add any value. Skipped few tests which are incomplete. Added timeout logic and to wait for router to boot. (cherry picked from commit a65f1ebefca7b22512762faf1832291153782f58) Signed-off-by: Sangeetha sangeetha.hariha...@citrix.com [Automation] test_egress_fw_rules.py fails with Script result is ['send: spawn id exp3 not open' '] is not matching with ['100'] in KVM --- Key: CLOUDSTACK-4637 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4637 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Reporter: Girish Shilamkar Assignee: Girish Shilamkar Priority: Critical Still fails Script result is ['send: spawn id exp3 not open', ' while executing', 'send ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=quiet root@10.1.1.183 ping -c 1 www.google.com; exit $?', '', ' (file /tmp/expect_script.exp line 4)'] is not matching with ['100'] begin captured logging testclient.testcase.TestEgressFWRules: DEBUG: Creating network with network offering: 05d985b1-ee1c-4b04-9cee-d6c97e43032d testclient.testcase.TestEgressFWRules: DEBUG: Created network with ID: 02187a7a-9afe-45ff-b9c3-069b00c731fc testclient.testcase.TestEgressFWRules: DEBUG: Deploying instance in the account: test-B0F0Z8 testclient.testcase.TestEgressFWRules: DEBUG: Deployed instance in account: test-B0F0Z8 testclient.testcase.TestEgressFWRules: DEBUG: Creating Egress FW rule for networkid=02187a7a-9afe-45ff-b9c3-069b00c731fc networkname=Test Network testclient.testcase.TestEgressFWRules: DEBUG: Created rule=fe84b110-8042-47d3-8b72-917607ab8811 testclient.testcase.TestEgressFWRules: DEBUG: expect_script #!/usr/bin/expect spawn ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=quiet -i /root/.ssh/id_rsa.cloud -p 3922 root@169.254.2.102 expect root@r-588-QA:~# send ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=quiet root@10.1.1.183 ping -c 1 www.google.com; exit $? expect root@10.1.1.183's password: send password interact expect_script paramiko.transport: DEBUG: starting thread (client mode): 0x204143d0L paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_5.3) paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha256', 'diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256', 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijndael-...@lysator.liu.se'] server encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256', 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijndael-...@lysator.liu.se'] client mac:['hmac-md5', 'hmac-sha1', 'umac...@openssh.com', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'umac...@openssh.com', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client compress:['none', 'z...@openssh.com'] server compress:['none', 'z...@openssh.com'] client lang:[''] server lang:[''] kex follows?False paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none paramiko.transport: DEBUG: Switch to new keys ... paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.223.50.66: 41aef5f507e1ddd99077b11f4bf26553 paramiko.transport: DEBUG: Trying discovered key 76be480fa6b8ad3b78082d6d19e4ee44 in /root/.ssh/id_rsa paramiko.transport: DEBUG: userauth is OK paramiko.transport: INFO: Authentication (publickey) failed. paramiko.transport: DEBUG: userauth is OK paramiko.transport: INFO: Authentication (password)
[jira] [Created] (CLOUDSTACK-4890) [VM snapshot] Do not delete VM snapshots until VM is expunged. Currently after VM is restored, unable to recover VM snapshots as these are destroyed
angeline shen created CLOUDSTACK-4890: - Summary: [VM snapshot] Do not delete VM snapshots until VM is expunged. Currently after VM is restored, unable to recover VM snapshots as these are destroyed Key: CLOUDSTACK-4890 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4890 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Environment: MSCloudPlatform-4.2.1-732-rhel6.3.tar.gz Hosts XS 6.2 Reporter: angeline shen Priority: Minor Fix For: 4.2.1 1. Create multiple VM snapshots for the same VM - say 3 snapshots - S1,S2,S3. 2. Destroy the Vm. 3. Restore VM. All VM snapshots are removed. It would be nice to be able to recover VM snapshots when VM is restored . -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4836) Restart network with cleanup=true won't reprogram remote access VPN users in the VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798688#comment-13798688 ] ASF subversion and git services commented on CLOUDSTACK-4836: - Commit 7d7bd2afdf4fcf9ddf06080f041ec0bbebf5d2f0 in branch refs/heads/4.2 from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7d7bd2a ] CLOUDSTACK-4836: Fix VPN user are not programmed after restart network Restart network with cleanup=true won't reprogram remote access VPN users in the VR --- Key: CLOUDSTACK-4836 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4836 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical Fix For: 4.2.1 After restart network with cleanup=true, there is no programming of VPN users of the new user, thus remote access VPN function is broken. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4752) Can't delete a network that lacks a DHCP in network offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798692#comment-13798692 ] Jijun commented on CLOUDSTACK-4752: --- i have the same issue, i create a QuickCloudNoServices Zone , and create new VMsuccessful, but when delete the VM , throw the same exception. 2013-10-16 12:53:44,601 WARN [cloud.vm.UserVmManagerImpl] (UserVm-Scavenger-1:null) Unable to expunge VM[User|ztest01] com.cloud.exception.UnsupportedServiceException: Service Dhcp is not supported in the network id=204 at com.cloud.network.dao.NetworkServiceMapDaoImpl.getProviderForServiceInNetwork(NetworkServiceMapDaoImpl.java:127) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.network.NetworkManagerImpl.getDhcpServiceProvider(NetworkManagerImpl.java:3681) at com.cloud.network.NetworkManagerImpl.isDhcpAccrossMultipleSubnetsSupported(NetworkManagerImpl.java:2522) at com.cloud.network.NetworkManagerImpl.removeNic(NetworkManagerImpl.java:2507) at com.cloud.network.NetworkManagerImpl.cleanupNics(NetworkManagerImpl.java:2463) at com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:475) at com.cloud.vm.UserVmManagerImpl.expunge(UserVmManagerImpl.java:1600) at com.cloud.vm.UserVmManagerImpl$ExpungeTask.run(UserVmManagerImpl.java:1769) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) 2013-10-16 12:53:44,616 DEBUG [storage.image.BaseImageStoreDriverImpl] (RemoteHostEndPoint-2:null) Performing image store createTemplate async callback 2013-10-16 12:53:46,402 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-2:null) Ping from 4 2013-10-16 12:53:46,487 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-3:null) Ping from 1 2013-10-16 12:53:46,492 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-4:null) Ping from 3 2013-10-16 12:53:46,504 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-5:null) Ping from 2 2013-10-16 12:53:47,788 DEBUG [storage.download.DownloadListener] (Timer-9:null) Scheduling timeout at 3 ms, TEMPLATE: 202 at host 1 Can't delete a network that lacks a DHCP in network offering Key: CLOUDSTACK-4752 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4752 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: John Beredimas Trying to delete a network that lacks DHCP in its network offering seems to fail. Relevant output from Cloudmonkey follows: cloudmonkey remove nicfromvirtualmachine virtualmachineid=a8d35e16-cb65-46c5-aa8d-d07e533326ee nicid=a95e9112-07f0-4b94-b6be-5aa58bd360b3 Async job 76cbd3e7-e97f-49b7-b177-176ff76a5927 failed Error 530, Service Dhcp is not supported in the network id=249 accountid = 2e64c73f-a173-419a-8dc8-6739aa4e4f9d -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-2792) Redundant router: Password is reset again after fail-over happened
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798743#comment-13798743 ] ASF subversion and git services commented on CLOUDSTACK-2792: - Commit 3c8be550f0dbde0e2cc8ca2d8c190e9e8d6daf9c in branch refs/heads/4.2 from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3c8be55 ] CLOUDSTACK-2792: Call savepassword.sh inside VR for Xen Also only set password when password service is running, thus avoid setting for redundant router BACKUP router. Redundant router: Password is reset again after fail-over happened -- Key: CLOUDSTACK-2792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.0.0 Reporter: Sheng Yang Assignee: Sheng Yang Fix For: 4.2.1 Consider this scenario with RVR and Password protected VM: 1. Both Master and Backup is running. 2. We reset the password on VM 3. Both Master and Backup have password; for example say; password1 4. VM boots up and requests for password; receives it from Master VR 5. Master VR sets the password to Saved_Password and Backup VR continues to keep password1 6. Backup VR goes down; it had password as password1 7. Maste VR is running 8. We reset the password; so the password is only changed to Master VR (as Backup VR is down); for example password2 9. VM boots up and requests the password; gets it as password2 10. Master VR sets the password to be Saved_Password 11. Now Master VR goes down 12. Backup VR was brought online (it still has password1) 13. Now we reboot the VM 14. It sends a password request 15. Backup VR (which is only available now; so is Master) sends the password as password1 User tries to login as password2 and he cannot; unless we reset the password again. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4786) Redundant router: the priority limitation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798742#comment-13798742 ] ASF subversion and git services commented on CLOUDSTACK-4786: - Commit 93188b449c177481cecafb35fc14f40da88ece07 in branch refs/heads/4.2 from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=93188b4 ] CLOUDSTACK-4786: Reset Redundant Router priority after all the routers are stopped This patch would reset the priority in such condition: 1. All redundant routers are stopped, e.g. due to network GC 2. User start one VM in the network 3. The routers would be brought up with reseted priority(100 99). This would resolve the issue of network GC result in lower limit of redundant router priority reached. Redundant router: the priority limitation - Key: CLOUDSTACK-4786 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4786 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Devices Affects Versions: 4.2.0 Reporter: Sheng Yang Assignee: Sheng Yang Fix For: 4.3.0 The limitation states that when using RVR, Network GC can run only 40 times or RVR can only be restarted 40 times or Guest VM can only be restart 40 times before having the need to restart the network with cleanup=true (downtime). Example: 1. Let us say there is one VM in an account/network, VM1. 2. It is using 1 network, say N1 and it's created from a network offering that has redundant router enabled. 3. When VM1 was launched, two RVRs were created, say R1 and R2. 4. At that time R1 has priority set to 100 and R2 99. This is the default behavior. 5. Network GC is set to run every 30 minutes. 6. Let us draw a base line here, VM1 is running, R1 is running and has priority set to 100, R2 is running as has priority set to 99. 7. Stop VM1. 8. Wait for 30+ minutes. 9. Check R1 and R2, they will be stopped. 10. Start VM1. 11. R1 and R2 will be started and their priorities will now be set to 99 and 98 resp. 12. If you repeat steps #7 through #10, you will observe that after 40 tries priorities of R1 and R2 would be 20 and 19. You will observe that the RVR won't start. It will complain about the priority being too low. The only workaround now is to restart network with cleanup=true, basically destroy old routers and create new ones. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-2792) Redundant router: Password is reset again after fail-over happened
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798745#comment-13798745 ] Sheng Yang commented on CLOUDSTACK-2792: VMware and KVM are also fixed, but not tested. QA please test the VMware and KVM. Redundant router: Password is reset again after fail-over happened -- Key: CLOUDSTACK-2792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.0.0 Reporter: Sheng Yang Assignee: Sheng Yang Fix For: 4.2.1 Consider this scenario with RVR and Password protected VM: 1. Both Master and Backup is running. 2. We reset the password on VM 3. Both Master and Backup have password; for example say; password1 4. VM boots up and requests for password; receives it from Master VR 5. Master VR sets the password to Saved_Password and Backup VR continues to keep password1 6. Backup VR goes down; it had password as password1 7. Maste VR is running 8. We reset the password; so the password is only changed to Master VR (as Backup VR is down); for example password2 9. VM boots up and requests the password; gets it as password2 10. Master VR sets the password to be Saved_Password 11. Now Master VR goes down 12. Backup VR was brought online (it still has password1) 13. Now we reboot the VM 14. It sends a password request 15. Backup VR (which is only available now; so is Master) sends the password as password1 User tries to login as password2 and he cannot; unless we reset the password again. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-2792) Redundant router: Password is reset again after fail-over happened
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-2792. Resolution: Fixed Redundant router: Password is reset again after fail-over happened -- Key: CLOUDSTACK-2792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.0.0 Reporter: Sheng Yang Assignee: Sheng Yang Fix For: 4.2.1 Consider this scenario with RVR and Password protected VM: 1. Both Master and Backup is running. 2. We reset the password on VM 3. Both Master and Backup have password; for example say; password1 4. VM boots up and requests for password; receives it from Master VR 5. Master VR sets the password to Saved_Password and Backup VR continues to keep password1 6. Backup VR goes down; it had password as password1 7. Maste VR is running 8. We reset the password; so the password is only changed to Master VR (as Backup VR is down); for example password2 9. VM boots up and requests the password; gets it as password2 10. Master VR sets the password to be Saved_Password 11. Now Master VR goes down 12. Backup VR was brought online (it still has password1) 13. Now we reboot the VM 14. It sends a password request 15. Backup VR (which is only available now; so is Master) sends the password as password1 User tries to login as password2 and he cannot; unless we reset the password again. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-2792) Redundant router: Password is reset again after fail-over happened
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798752#comment-13798752 ] ASF subversion and git services commented on CLOUDSTACK-2792: - Commit 484d6c4eb741c882e1cc512ab35918d694e855c7 in branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=484d6c4 ] CLOUDSTACK-2792: Call savepassword.sh inside VR Also only set password when password service is running, thus avoid setting for redundant router BACKUP router. Redundant router: Password is reset again after fail-over happened -- Key: CLOUDSTACK-2792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.0.0 Reporter: Sheng Yang Assignee: Sheng Yang Fix For: 4.2.1 Consider this scenario with RVR and Password protected VM: 1. Both Master and Backup is running. 2. We reset the password on VM 3. Both Master and Backup have password; for example say; password1 4. VM boots up and requests for password; receives it from Master VR 5. Master VR sets the password to Saved_Password and Backup VR continues to keep password1 6. Backup VR goes down; it had password as password1 7. Maste VR is running 8. We reset the password; so the password is only changed to Master VR (as Backup VR is down); for example password2 9. VM boots up and requests the password; gets it as password2 10. Master VR sets the password to be Saved_Password 11. Now Master VR goes down 12. Backup VR was brought online (it still has password1) 13. Now we reboot the VM 14. It sends a password request 15. Backup VR (which is only available now; so is Master) sends the password as password1 User tries to login as password2 and he cannot; unless we reset the password again. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4786) Redundant router: the priority limitation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798751#comment-13798751 ] ASF subversion and git services commented on CLOUDSTACK-4786: - Commit 85dc65c7f766e76ff57816127578adca5ade1c54 in branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=85dc65c ] CLOUDSTACK-4786: Reset Redundant Router priority after all the routers are stopped This patch would reset the priority in such condition: 1. All redundant routers are stopped, e.g. due to network GC 2. User start one VM in the network 3. The routers would be brought up with reseted priority(100 99). This would resolve the issue of network GC result in lower limit of redundant router priority reached. Redundant router: the priority limitation - Key: CLOUDSTACK-4786 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4786 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Devices Affects Versions: 4.2.0 Reporter: Sheng Yang Assignee: Sheng Yang Fix For: 4.2.1 The limitation states that when using RVR, Network GC can run only 40 times or RVR can only be restarted 40 times or Guest VM can only be restart 40 times before having the need to restart the network with cleanup=true (downtime). Example: 1. Let us say there is one VM in an account/network, VM1. 2. It is using 1 network, say N1 and it's created from a network offering that has redundant router enabled. 3. When VM1 was launched, two RVRs were created, say R1 and R2. 4. At that time R1 has priority set to 100 and R2 99. This is the default behavior. 5. Network GC is set to run every 30 minutes. 6. Let us draw a base line here, VM1 is running, R1 is running and has priority set to 100, R2 is running as has priority set to 99. 7. Stop VM1. 8. Wait for 30+ minutes. 9. Check R1 and R2, they will be stopped. 10. Start VM1. 11. R1 and R2 will be started and their priorities will now be set to 99 and 98 resp. 12. If you repeat steps #7 through #10, you will observe that after 40 tries priorities of R1 and R2 would be 20 and 19. You will observe that the RVR won't start. It will complain about the priority being too low. The only workaround now is to restart network with cleanup=true, basically destroy old routers and create new ones. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4786) Redundant router: the priority limitation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang updated CLOUDSTACK-4786: --- Fix Version/s: (was: 4.3.0) 4.2.1 Redundant router: the priority limitation - Key: CLOUDSTACK-4786 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4786 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Devices Affects Versions: 4.2.0 Reporter: Sheng Yang Assignee: Sheng Yang Fix For: 4.2.1 The limitation states that when using RVR, Network GC can run only 40 times or RVR can only be restarted 40 times or Guest VM can only be restart 40 times before having the need to restart the network with cleanup=true (downtime). Example: 1. Let us say there is one VM in an account/network, VM1. 2. It is using 1 network, say N1 and it's created from a network offering that has redundant router enabled. 3. When VM1 was launched, two RVRs were created, say R1 and R2. 4. At that time R1 has priority set to 100 and R2 99. This is the default behavior. 5. Network GC is set to run every 30 minutes. 6. Let us draw a base line here, VM1 is running, R1 is running and has priority set to 100, R2 is running as has priority set to 99. 7. Stop VM1. 8. Wait for 30+ minutes. 9. Check R1 and R2, they will be stopped. 10. Start VM1. 11. R1 and R2 will be started and their priorities will now be set to 99 and 98 resp. 12. If you repeat steps #7 through #10, you will observe that after 40 tries priorities of R1 and R2 would be 20 and 19. You will observe that the RVR won't start. It will complain about the priority being too low. The only workaround now is to restart network with cleanup=true, basically destroy old routers and create new ones. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-2792) Redundant router: Password is reset again after fail-over happened
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang updated CLOUDSTACK-2792: --- Priority: Critical (was: Major) Redundant router: Password is reset again after fail-over happened -- Key: CLOUDSTACK-2792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.0.0 Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical Fix For: 4.2.1 Consider this scenario with RVR and Password protected VM: 1. Both Master and Backup is running. 2. We reset the password on VM 3. Both Master and Backup have password; for example say; password1 4. VM boots up and requests for password; receives it from Master VR 5. Master VR sets the password to Saved_Password and Backup VR continues to keep password1 6. Backup VR goes down; it had password as password1 7. Maste VR is running 8. We reset the password; so the password is only changed to Master VR (as Backup VR is down); for example password2 9. VM boots up and requests the password; gets it as password2 10. Master VR sets the password to be Saved_Password 11. Now Master VR goes down 12. Backup VR was brought online (it still has password1) 13. Now we reboot the VM 14. It sends a password request 15. Backup VR (which is only available now; so is Master) sends the password as password1 User tries to login as password2 and he cannot; unless we reset the password again. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-2792) Redundant router: Password is reset again after fail-over happened
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798753#comment-13798753 ] Sheng Yang commented on CLOUDSTACK-2792: And it would affect the basic functionality of password enabled VM, so QA must test this. Redundant router: Password is reset again after fail-over happened -- Key: CLOUDSTACK-2792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.0.0 Reporter: Sheng Yang Assignee: Sheng Yang Fix For: 4.2.1 Consider this scenario with RVR and Password protected VM: 1. Both Master and Backup is running. 2. We reset the password on VM 3. Both Master and Backup have password; for example say; password1 4. VM boots up and requests for password; receives it from Master VR 5. Master VR sets the password to Saved_Password and Backup VR continues to keep password1 6. Backup VR goes down; it had password as password1 7. Maste VR is running 8. We reset the password; so the password is only changed to Master VR (as Backup VR is down); for example password2 9. VM boots up and requests the password; gets it as password2 10. Master VR sets the password to be Saved_Password 11. Now Master VR goes down 12. Backup VR was brought online (it still has password1) 13. Now we reboot the VM 14. It sends a password request 15. Backup VR (which is only available now; so is Master) sends the password as password1 User tries to login as password2 and he cannot; unless we reset the password again. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar reassigned CLOUDSTACK-4792: -- Assignee: Anshul Gangwar (was: Milamber) Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798768#comment-13798768 ] Anshul Gangwar commented on CLOUDSTACK-4792: Sorry for not updating the jira. Fix for this is already submitted on review board https://reviews.apache.org/r/14467/ Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar updated CLOUDSTACK-4792: --- Status: Ready To Review (was: In Progress) Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-1899) SRX firewall external devices - static NAT does not function
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy resolved CLOUDSTACK-1899. --- Resolution: Cannot Reproduce It worked for me. No route to host, It might be srx route setup issue. SRX firewall external devices - static NAT does not function Key: CLOUDSTACK-1899 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1899 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.0.0 Environment: MSASF 4.0.0 GA RHEL6.3 host KVM ASF 4.0.0 GA RHEL6.3 Reporter: angeline shen Assignee: Jayapal Reddy Fix For: 4.3.0 1. advance zone, create network offering for external device firewall SRX, add SRX device 2. create instances using above network offering. Port forwarding rules work. allocate public IP, enable static NAT, set TCP port 22 rule for IP. ssh to static NAT IP FAIL: [ashen@localhost ~]$ ssh root@10.223.123.22 ssh: connect to host 10.223.123.22 port 22: No route to hos 3. create VPC, VPC network, instances. Both static NAT and Port forwarding rules work for VPC network -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-3994) Wrong error notification is generated when Primary storage (Cluster wide) is added with wrong path
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshul Gangwar resolved CLOUDSTACK-3994.
Resolution: Fixed
Fix Version/s: 4.2.1
returning false when one tries to delete non-existent storage pool
Wrong error notification is generated when Primary storage (Cluster wide) is
added with wrong path
--
Key: CLOUDSTACK-3994
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3994
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller, VMware
Affects Versions: 4.2.0
Reporter: Sailaja Mada
Priority: Minor
Fix For: 4.2.1, 4.3.0
Attachments: apilog.log, management-server.log
Steps:
1. Configure Adv Zone with VMWARE
2. Tried to add wrong cluster wide primary storage point
It failed saying Failed to delete storage pool on host
2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-230:null) Seq 1-757532143: Executing request
2013-08-01 10:00:12,928 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-230:null) Seq 1-757532143: Response Received:
2013-08-01 10:00:12,929 DEBUG [agent.transport.Request]
(DirectAgent-230:null) Seq 1-757532143: Processing: { Ans: , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:true,details:success,wait:0}}]
}
2013-08-01 10:00:12,933 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-757532143: Received: { Ans: , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 10, { Answer } }
2013-08-01 10:00:12,933 DEBUG [agent.manager.AgentManagerImpl]
(catalina-exec-23:null) Details from executing class
com.cloud.agent.api.CreateStoragePoolCommand: success
2013-08-01 10:00:12,933 DEBUG
[datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl]
(catalina-exec-23:null) In createPool Adding the pool to each of the hosts
2013-08-01 10:00:12,935 DEBUG [cloud.storage.StorageManagerImpl]
(catalina-exec-23:null) Adding pool null to host 1
2013-08-01 10:00:12,940 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-757532144: Sending { Cmd , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 100011,
[{com.cloud.agent.api.ModifyStoragePoolCommand:{add:true,pool:{id:5,uuid:86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,host:10.102.192.100,path:/cpg_vol/sailaja/ps1,port:2049,type:NetworkFilesystem},localPath:/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,wait:0}}]
}
2013-08-01 10:00:12,941 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-757532144: Executing: { Cmd , MgmtId:
187767034175903, via: 1, Ver: v1, Flags: 100011,
[{com.cloud.agent.api.ModifyStoragePoolCommand:{add:true,pool:{id:5,uuid:86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,host:10.102.192.100,path:/cpg_vol/sailaja/ps1,port:2049,type:NetworkFilesystem},localPath:/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,wait:0}}]
}
2013-08-01 10:00:12,941 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-230:null) Seq 1-757532144: Executing request
2013-08-01 10:00:12,942 INFO [vmware.resource.VmwareResource]
(DirectAgent-230:10.102.192.18) Executing resource ModifyStoragePoolCommand:
{add:true,pool:{id:5,uuid:86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,host:10.102.192.100,path:/cpg_vol/sailaja/ps1,port:2049,type:NetworkFilesystem},localPath:/mnt//86ee5258-33e7-36f0-b3c1-f6029e5c8bdf,wait:0}
2013-08-01 10:00:13,144 INFO [vmware.mo.HostMO]
(DirectAgent-230:10.102.192.18) Creation of NFS datastore on vCenter failed.
Details: vCenter API trace - mountDatastore(). target MOR: host-8973, vmfs:
false, poolHost: 10.102.192.100, poolHostPort: 2049, poolPath:
/cpg_vol/sailaja/ps1, poolUuid: 86ee525833e736f0b3c1f6029e5c8bdf. Exception
mesg: An error occurred during host configuration.
2013-08-01 10:00:13,145 ERROR [vmware.resource.VmwareResource]
(DirectAgent-230:10.102.192.18) ModifyStoragePoolCommand failed due to
Exception: java.lang.Exception
Message: Creation of NFS datastore on vCenter failed.
java.lang.Exception: Creation of NFS datastore on vCenter failed.
at
com.cloud.hypervisor.vmware.mo.HostMO.mountDatastore(HostMO.java:772)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4102)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:472)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at
[jira] [Reopened] (CLOUDSTACK-1637) LDAP:UI related issues
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sadhu suresh reopened CLOUDSTACK-1637: -- registered details shown in the UI but quick view is not showing the registered details. LDAP:UI related issues -- Key: CLOUDSTACK-1637 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1637 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: sadhu suresh Fix For: 4.3.0 case 1:Clear the port number value when we check the ssl check box. when we check the SSL ,Port value shows 389 but required value is 636. expected result: when ssl enabled ,clear the default389 value from port field and restrict the user to enter value.so that end user enter proper value(in case of AD its 636) Case2: no automatic page refresh when we configured new LDAP,i.e we are seeing both records(current and previous configuration details) till you refresh the page manually. Steps: 1.configured the LDAP from UI 2.again congured the another LDAP 3.check the UI Actual result: able to see both previous and current LDAP configuration details till you refresh the page manually. once you fresh it showing the correct details. Expected results: when we add new LDAP configuration details,previous details should be overwritten with current value and same thing should be reflected in UI automatically instead of showing both details till you refresh the page. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4783) Unable to see a derieved template if the parent template is deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-4783: --- Assignee: (was: Harikrishna Patnala) Unable to see a derieved template if the parent template is deleted --- Key: CLOUDSTACK-4783 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4783 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.2.0 Reporter: Nitin Mehta Priority: Critical Fix For: 4.2.1 Functionality required/broken – For a template, if the parent template info (template Id) is provided in the listTemplates API then one should be able to query for the parent template id as well (whether existing/removed doesn't matter) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4783) Unable to see a derieved template if the parent template is deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-4783: --- Assignee: Kishan Kavala Unable to see a derieved template if the parent template is deleted --- Key: CLOUDSTACK-4783 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4783 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Kishan Kavala Priority: Critical Fix For: 4.2.1 Functionality required/broken – For a template, if the parent template info (template Id) is provided in the listTemplates API then one should be able to query for the parent template id as well (whether existing/removed doesn't matter) -- This message was sent by Atlassian JIRA (v6.1#6144)
