[jira] [Commented] (CLOUDSTACK-5946) SSL: Fail to find the generated keystore. Loading fail-safe one to continue.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919186#comment-13919186 ] Wei Zhou commented on CLOUDSTACK-5946: -- Vadim, Can you paste full log near 2014-03-03 17:14:07,923 ? Thanks! -Wei SSL: Fail to find the generated keystore. Loading fail-safe one to continue. Key: CLOUDSTACK-5946 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5946 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.1 Environment: CentOS 6.4 x64 Reporter: Vadim Kim. Priority: Minor Management logs are full of this warning. deleting file /etc/cloudstack/management/cloudmanagementserver.keystore seems to fix the problem. System re-crates it later and does not issue warnings anymore -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6181) Root resize
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919187#comment-13919187 ] Nux commented on CLOUDSTACK-6181: - Marcus, This is great! I'll start testing as well shortly and bug Mike and Wido on the ml for their blessings. Root resize --- Key: CLOUDSTACK-6181 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6181 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Storage Controller, UI Affects Versions: 4.4.0 Environment: KVM/libvirt/CentOS, Xenserver Reporter: Nux Labels: disk, resize, template Fix For: 4.4.0 Rationale: Currently the root size of an instance is locked to that of the template. This creates unnecessary template duplicates, prevents the creation of a market place, wastes time and disk space and generally makes work more complicated. Real life example - a small VPS provider might want to offer the following sizes (in GB): 10,20,40,80,160,240,320,480,620 That's 9 offerings. The template selection could look like this, including real disk space used: Windows 2008 ~10GB Windows 2008+Plesk ~15GB Windows 2008+MSSQL ~15GB Windows 2012 ~10GB Windows 2012+Plesk ~15GB Windows 2012+MSSQL ~15GB CentOS ~1GB CentOS+CPanel ~3GB CentOS+Virtualmin ~3GB CentOS+Zimbra ~3GB CentOS+Docker ~2GB Debian ~1GB Ubuntu LTS ~1GB In this case the total disk space used by templates will be 828 GB, that's almost 1 TB. If your storage is expensive and limited SSD this can get painful! If the root resize feature is enabled we can reduce this to under 100 GB. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6181) Root resize
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919192#comment-13919192 ] Nux commented on CLOUDSTACK-6181: - I'll also test for GlusterFS. Root resize --- Key: CLOUDSTACK-6181 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6181 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Storage Controller, UI Affects Versions: 4.4.0 Environment: KVM/libvirt/CentOS, Xenserver Reporter: Nux Labels: disk, resize, template Fix For: 4.4.0 Rationale: Currently the root size of an instance is locked to that of the template. This creates unnecessary template duplicates, prevents the creation of a market place, wastes time and disk space and generally makes work more complicated. Real life example - a small VPS provider might want to offer the following sizes (in GB): 10,20,40,80,160,240,320,480,620 That's 9 offerings. The template selection could look like this, including real disk space used: Windows 2008 ~10GB Windows 2008+Plesk ~15GB Windows 2008+MSSQL ~15GB Windows 2012 ~10GB Windows 2012+Plesk ~15GB Windows 2012+MSSQL ~15GB CentOS ~1GB CentOS+CPanel ~3GB CentOS+Virtualmin ~3GB CentOS+Zimbra ~3GB CentOS+Docker ~2GB Debian ~1GB Ubuntu LTS ~1GB In this case the total disk space used by templates will be 828 GB, that's almost 1 TB. If your storage is expensive and limited SSD this can get painful! If the root resize feature is enabled we can reduce this to under 100 GB. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-4126) EN: Typo error after click Migrate instance to another host button under instances tab.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919217#comment-13919217 ] Mihaela Stoica commented on CLOUDSTACK-4126: This has been fixed in: Commit e171cb181c150ebdb140ffca575aad8c1b294fee in cloudstack's branch refs/heads/master from vetrivelc vetrivel.chinnas...@citrix.com [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e171cb18 ] Fixed-Hardcoding-Issues EN: Typo error after click Migrate instance to another host button under instances tab. --- Key: CLOUDSTACK-4126 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4126 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.0 Environment: Build#CloudPlatform-4.2-343(CloudPlatform-4.2-343-rhel6.3.tar.gz) XenServer6.1 for Host Server CentOS6.3 for NFS, CS-Mgr Servers. Reporter: Minying Bao Priority: Minor Attachments: Typo error.jpg Prerequisite Upload a Template/ISO. then created vm in instances tab. Repro Steps 1. Open the browser and login to Web Portal. 2. Navigate the “instances” tab. 3. Click to the newly created vm. 4. Click “Migrate instance to another host” button.. 5. Observe the UI. Expected Result It should shows “No Hosts are available for Migrate”. Actual Result Typo error occurred on avaialble. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5583) vmopsSnapshot plug-in (XenServer) does not return an error when it should
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919219#comment-13919219 ] Mandar Barve commented on CLOUDSTACK-5583: -- Hi, I tried to reproduce the issue but couldn't get this to fail for insufficient space. I then injected an exception trying to list files from a non existent path (added this code in the try block). This landed me into the exception handling code. It raised correct exception saying file not found which was captured in the management server vmops log file. It was not displayed by the GUI. GUI just reported Error. The plugin code returns 0 immediately after the line of code that raises exception but I think this applies only for successful execution of the plugin code that reverts the snapshot. If any exception is raised (e.g. in the reported case here insufficient space) then the code should return appropriate error message to the caller as I found. In exception handling path return 0 wouldn't execute. Can you please double check or let me know if I am missing anything? Thanks, Mandar vmopsSnapshot plug-in (XenServer) does not return an error when it should - Key: CLOUDSTACK-5583 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5583 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Xen Affects Versions: 4.3.0 Environment: XenServer 6.1 Reporter: Mike Tutkowski Fix For: 4.3.0 I tried to revert a VM snapshot and one of my storage repositories had an insufficient amount of space. The plug-in did not return an error message (it returned 0). From the XenServer vmopsSnapshot plug-in's revert_memory_snapshot method: [root@XenServer-6 ~]# xe snapshot-revert snapshot-uuid=82e33f6d-59f3-a26d-4171-d51cd58716d8 Error code: SR_BACKEND_FAILURE_44 Error parameters: , There is insufficient space, An error should be returned from the plug-in instead of 0. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6147) Automation - Add automation test cases for Dynamic Compute Offering Feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye resolved CLOUDSTACK-6147. Resolution: Fixed Work completed. Will close the task once patch is committed. Automation - Add automation test cases for Dynamic Compute Offering Feature --- Key: CLOUDSTACK-6147 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6147 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-4840) Automation: multiple IPs per NIC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919237#comment-13919237 ] Ashutosk Kelkar commented on CLOUDSTACK-4840: - Adding last patch today. Automation: multiple IPs per NIC - Key: CLOUDSTACK-4840 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4840 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Reporter: Sudha Ponnaganti Assignee: Ashutosk Kelkar Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6195) an ACS db upgraded from Pre-4.0 version is missing unique key constraint on host_details
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919294#comment-13919294 ] Joris van Lieshout commented on CLOUDSTACK-6195: Hi Wei Zhou, Thank you for having a look. If I check the schema-create script of 2.2.14 (https://github.com/CloudStack-extras/CloudStack-archive/blob/2.2.14/setup/db/create-schema.sql) I see that the constraint is not there. I will check if the scripts of 3.0.0, 3.0.1 and 3.0.2 as well and update this ticket. Our upgrade path up until 4.0 is the same as yours. 1 2.2.14.20120210102939 2012-03-20 19:46:38 Complete 2 3.0.0 2012-06-22 12:48:19 Complete 3 3.0.1 2012-06-22 12:48:19 Complete 4 3.0.2 2012-06-22 12:48:19 Complete 7 4.0.0 2012-08-21 13:00:14 Complete 9 4.0.1 2013-02-13 12:36:24 Complete 11 4.0.2 2013-04-23 07:21:08 Complete 13 4.1.0 2013-07-16 09:43:23 Complete 15 4.1.1 2013-07-16 09:43:23 Complete 17 4.2.0 2013-12-18 09:38:25 Complete 19 4.2.1 2013-12-18 09:38:25 Complete an ACS db upgraded from Pre-4.0 version is missing unique key constraint on host_details Key: CLOUDSTACK-6195 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6195 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0, 4.2.1, 4.1.2 Environment: Pre-4.0 db upgraded to 4.x. We have confirmed this bug in a db that started out as 2.2.14. Reporter: Joris van Lieshout This is the table in our 4.2.1 env that has been upgraded from 2.2.14. CREATE TABLE `host_details` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `host_id` bigint(20) unsigned NOT NULL COMMENT 'host id', `name` varchar(255) NOT NULL, `value` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `fk_host_details__host_id` (`host_id`), CONSTRAINT `fk_host_details__host_id` FOREIGN KEY (`host_id`) REFERENCES `host` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=752966 DEFAULT CHARSET=utf8; And this is the table of a fresh 4.x install: CREATE TABLE `host_details` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `host_id` bigint(20) unsigned NOT NULL COMMENT 'host id', `name` varchar(255) NOT NULL, `value` varchar(255) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_host_id_name` (`host_id`,`name`), KEY `fk_host_details__host_id` (`host_id`), CONSTRAINT `fk_host_details__host_id` FOREIGN KEY (`host_id`) REFERENCES `host` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=242083 DEFAULT CHARSET=utf8; The effect of this missing bug is a lot of duplicate entries in the host_details table. The duplicate information on the host_details table causes the api call listHosts to return the same host tag multiple time (to be exact: the number of duplicate entries in the host_details table for that host). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6195) an ACS db upgraded from Pre-4.0 version is missing unique key constraint on host_details
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919320#comment-13919320 ] Wei Zhou commented on CLOUDSTACK-6195: -- https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=tree;f=server/src/com/cloud/upgrade/dao;h=4c697164dccd08c483b44d2ccadd31e16f04ee05;hb=6355965dcd956811dd471a9d03c73dadcf68f480 line 512 to 542 in Upgrade302to40.java. The commit 0b31a0af6232e15618214983dfa4659b5dc6797c was commited on 2012-08-21 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=0b31a0af6232e15618214983dfa4659b5dc6797c https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=aec6b4af48c407a8e055656f0183f8d6eae1c9e2 Maybe your installation packages did not include it? an ACS db upgraded from Pre-4.0 version is missing unique key constraint on host_details Key: CLOUDSTACK-6195 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6195 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0, 4.2.1, 4.1.2 Environment: Pre-4.0 db upgraded to 4.x. We have confirmed this bug in a db that started out as 2.2.14. Reporter: Joris van Lieshout This is the table in our 4.2.1 env that has been upgraded from 2.2.14. CREATE TABLE `host_details` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `host_id` bigint(20) unsigned NOT NULL COMMENT 'host id', `name` varchar(255) NOT NULL, `value` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `fk_host_details__host_id` (`host_id`), CONSTRAINT `fk_host_details__host_id` FOREIGN KEY (`host_id`) REFERENCES `host` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=752966 DEFAULT CHARSET=utf8; And this is the table of a fresh 4.x install: CREATE TABLE `host_details` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `host_id` bigint(20) unsigned NOT NULL COMMENT 'host id', `name` varchar(255) NOT NULL, `value` varchar(255) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_host_id_name` (`host_id`,`name`), KEY `fk_host_details__host_id` (`host_id`), CONSTRAINT `fk_host_details__host_id` FOREIGN KEY (`host_id`) REFERENCES `host` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=242083 DEFAULT CHARSET=utf8; The effect of this missing bug is a lot of duplicate entries in the host_details table. The duplicate information on the host_details table causes the api call listHosts to return the same host tag multiple time (to be exact: the number of duplicate entries in the host_details table for that host). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6195) an ACS db upgraded from Pre-4.0 version is missing unique key constraint on host_details
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919321#comment-13919321 ] Wei Zhou commented on CLOUDSTACK-6195: -- 4.0.0-incubating was released on 6th Nov 2012. Why did you upgrade to 4.0.0 on 2012-08-21? an ACS db upgraded from Pre-4.0 version is missing unique key constraint on host_details Key: CLOUDSTACK-6195 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6195 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0, 4.2.1, 4.1.2 Environment: Pre-4.0 db upgraded to 4.x. We have confirmed this bug in a db that started out as 2.2.14. Reporter: Joris van Lieshout This is the table in our 4.2.1 env that has been upgraded from 2.2.14. CREATE TABLE `host_details` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `host_id` bigint(20) unsigned NOT NULL COMMENT 'host id', `name` varchar(255) NOT NULL, `value` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `fk_host_details__host_id` (`host_id`), CONSTRAINT `fk_host_details__host_id` FOREIGN KEY (`host_id`) REFERENCES `host` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=752966 DEFAULT CHARSET=utf8; And this is the table of a fresh 4.x install: CREATE TABLE `host_details` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `host_id` bigint(20) unsigned NOT NULL COMMENT 'host id', `name` varchar(255) NOT NULL, `value` varchar(255) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_host_id_name` (`host_id`,`name`), KEY `fk_host_details__host_id` (`host_id`), CONSTRAINT `fk_host_details__host_id` FOREIGN KEY (`host_id`) REFERENCES `host` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=242083 DEFAULT CHARSET=utf8; The effect of this missing bug is a lot of duplicate entries in the host_details table. The duplicate information on the host_details table causes the api call listHosts to return the same host tag multiple time (to be exact: the number of duplicate entries in the host_details table for that host). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6035) error when displaying firewall rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919332#comment-13919332 ] Tomasz Zieba commented on CLOUDSTACK-6035: -- Problem exists on Firefox. Chrome is not affected. error when displaying firewall rules Key: CLOUDSTACK-6035 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6035 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.1 Environment: ACS 4.2.1 after upgrade from 3.0.2 Reporter: Tomasz Zieba Attachments: CS_firewall_4.2.JPG, cloudstack_ui_firewall_error.JPG After upgrade from 3.0.2 to 4.2.1. In version 4.2.1 there was an error when displaying firewall rules. If the number of rules is too high UI displays an error (screenshot attached). In the illustrated case it is 26 rules. There wasn't this bug in 3.0.2 version. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6195) an ACS db upgraded from Pre-4.0 version is missing unique key constraint on host_details
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919341#comment-13919341 ] Joris van Lieshout commented on CLOUDSTACK-6195: Hi Wei Zhou, We were really looking forward to 4.x I guess. :) Anyway, this explains the issue. We've already fixed the constraint and will be doing a schema compare to make sure this was the only discrepancy. I've created this ticket as a courtesy just in case any one else would run into this. Good to hear we're probably the only one. :) For me case closed as non-issue. Thanks again! an ACS db upgraded from Pre-4.0 version is missing unique key constraint on host_details Key: CLOUDSTACK-6195 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6195 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0, 4.2.1, 4.1.2 Environment: Pre-4.0 db upgraded to 4.x. We have confirmed this bug in a db that started out as 2.2.14. Reporter: Joris van Lieshout This is the table in our 4.2.1 env that has been upgraded from 2.2.14. CREATE TABLE `host_details` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `host_id` bigint(20) unsigned NOT NULL COMMENT 'host id', `name` varchar(255) NOT NULL, `value` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `fk_host_details__host_id` (`host_id`), CONSTRAINT `fk_host_details__host_id` FOREIGN KEY (`host_id`) REFERENCES `host` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=752966 DEFAULT CHARSET=utf8; And this is the table of a fresh 4.x install: CREATE TABLE `host_details` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `host_id` bigint(20) unsigned NOT NULL COMMENT 'host id', `name` varchar(255) NOT NULL, `value` varchar(255) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_host_id_name` (`host_id`,`name`), KEY `fk_host_details__host_id` (`host_id`), CONSTRAINT `fk_host_details__host_id` FOREIGN KEY (`host_id`) REFERENCES `host` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=242083 DEFAULT CHARSET=utf8; The effect of this missing bug is a lot of duplicate entries in the host_details table. The duplicate information on the host_details table causes the api call listHosts to return the same host tag multiple time (to be exact: the number of duplicate entries in the host_details table for that host). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6195) an ACS db upgraded from Pre-4.0 version is missing unique key constraint on host_details
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou closed CLOUDSTACK-6195. Resolution: Invalid an ACS db upgraded from Pre-4.0 version is missing unique key constraint on host_details Key: CLOUDSTACK-6195 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6195 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0, 4.2.1, 4.1.2 Environment: Pre-4.0 db upgraded to 4.x. We have confirmed this bug in a db that started out as 2.2.14. Reporter: Joris van Lieshout This is the table in our 4.2.1 env that has been upgraded from 2.2.14. CREATE TABLE `host_details` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `host_id` bigint(20) unsigned NOT NULL COMMENT 'host id', `name` varchar(255) NOT NULL, `value` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `fk_host_details__host_id` (`host_id`), CONSTRAINT `fk_host_details__host_id` FOREIGN KEY (`host_id`) REFERENCES `host` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=752966 DEFAULT CHARSET=utf8; And this is the table of a fresh 4.x install: CREATE TABLE `host_details` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `host_id` bigint(20) unsigned NOT NULL COMMENT 'host id', `name` varchar(255) NOT NULL, `value` varchar(255) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_host_id_name` (`host_id`,`name`), KEY `fk_host_details__host_id` (`host_id`), CONSTRAINT `fk_host_details__host_id` FOREIGN KEY (`host_id`) REFERENCES `host` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=242083 DEFAULT CHARSET=utf8; The effect of this missing bug is a lot of duplicate entries in the host_details table. The duplicate information on the host_details table causes the api call listHosts to return the same host tag multiple time (to be exact: the number of duplicate entries in the host_details table for that host). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-4445) [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter with Chrome Browser
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada closed CLOUDSTACK-4445. This is not observed now. Hence closing the bug. [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter with Chrome Browser -- Key: CLOUDSTACK-4445 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4445 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.1 Reporter: Sailaja Mada Assignee: Brian Federle Fix For: 4.3.0 Attachments: addremovedc.png, dedicatePOD1.png, dedicatecluster1.png, dedicatehost1.png, dedicatezone1.png Observation : Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter . Expected behavior : We should have icons to identify these new options separately. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-1889) [UI] Consumed Resource usage details are not available for all the resources
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada closed CLOUDSTACK-1889. This is displayed with update Resource count and hence closing the bug. Instance Count: 4 Public IP Count: 0 Volume Count: 4 Snapshot Count: 0 Template Count: 5 Network Count: 0 VPC Count: 0 CPU Count: 7 Memory Count: 7658 Primary Storage Count: 80530636800 Secondary Storage Count: 15882002432 [UI] Consumed Resource usage details are not available for all the resources Key: CLOUDSTACK-1889 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1889 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.0 Reporter: Sailaja Mada Assignee: Jessica Wang Fix For: 4.3.0 Attachments: ConsumedresourcesUSage.png, Page1.jpg, Page2.jpg, Page3.jpg, jessica_2013_10_10.PNG, new.rar, resources.png, updateResourceCount_out.xml, when_updateResourceCount_action_finishes.jpg Setup: Advanced Networking zone with Xen 6.1 [4.2] Steps: 1. Create Child domain (CDC1) under ROOT 2. Create Domain account CDC1Admin1 under Child Domain CDC1 3. Access Management Server as this domain admin account 4. Deploy VM with this account 5. Tried to update resource Count Observation: Consumed Resource usage details are not available for all the resources. It is available only with Total of VM , Total of IP Address , Bytes Received ,Bytes Sent. API provides the details. http://10.102.192.208:8096/client/api?command=updateResourceCountdomainid=2resourcetype=9account=cdc1admin1 updateresourcecountresponse cloud-stack-version=4.2.0-SNAPSHOTcount1/countresourcecountaccountcdc1admin1/accountdomainide8377899-c351-47a2-aed5-92c624eebae5/domainiddomaincdc1/domainresourcetype9/resourcetyperesourcecount512/resourcecount/resourcecount/updateresourcecountresponse -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6181) Root resize
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919499#comment-13919499 ] Wido den Hollander commented on CLOUDSTACK-6181: I haven't tested the RBD code, but reading the code doesn't show me anything that won't work. RBD doesn't care if you create a big image and don't fully fill it. Looking through the code it seems that you haven't touched anything that would really break. Root resize --- Key: CLOUDSTACK-6181 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6181 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Storage Controller, UI Affects Versions: 4.4.0 Environment: KVM/libvirt/CentOS, Xenserver Reporter: Nux Labels: disk, resize, template Fix For: 4.4.0 Rationale: Currently the root size of an instance is locked to that of the template. This creates unnecessary template duplicates, prevents the creation of a market place, wastes time and disk space and generally makes work more complicated. Real life example - a small VPS provider might want to offer the following sizes (in GB): 10,20,40,80,160,240,320,480,620 That's 9 offerings. The template selection could look like this, including real disk space used: Windows 2008 ~10GB Windows 2008+Plesk ~15GB Windows 2008+MSSQL ~15GB Windows 2012 ~10GB Windows 2012+Plesk ~15GB Windows 2012+MSSQL ~15GB CentOS ~1GB CentOS+CPanel ~3GB CentOS+Virtualmin ~3GB CentOS+Zimbra ~3GB CentOS+Docker ~2GB Debian ~1GB Ubuntu LTS ~1GB In this case the total disk space used by templates will be 828 GB, that's almost 1 TB. If your storage is expensive and limited SSD this can get painful! If the root resize feature is enabled we can reduce this to under 100 GB. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6162) support OVS as connectivity service provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919518#comment-13919518 ] ASF subversion and git services commented on CLOUDSTACK-6162: - Commit e8e431aeca3e16cd34fa8d933722d643ba0de56a in cloudstack's branch refs/heads/4.3-forward from [~ng.tuna] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e8e431a ] CLOUDSTACK-6162: add UI for OVS plugin - update old version support OVS as connectivity service provider Key: CLOUDSTACK-6162 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6162 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.3.0 Attachments: jessica-2014-02-25.PNG, jessica-2014-02-25B.PNG Below UI changes are needed to enable OVS as connectivity provider while creating network offering. Below changes are required: 1) In the drop down box for 'Connectivity' service provider in the network offering dialog box, expose Ovs as provider. And corresponding API call would be: http://192.168.20.112:8080/client/api?command=createNetworkOfferingsessionkey=0YutiBb19VkXgepJYf/wq2Wii4Q=name=ovs-connectivity-offeringdisplayText=ovs-connectivity-offeringguestIpType=IsolatedlbType=publicLbservicecapabilitylist[0].service=SourceNatservicecapabilitylist[0].capabilitytype=SupportedSourceNatTypesservicecapabilitylist[0].capabilityvalue=peraccountservicecapabilitylist[1].service=lbservicecapabilitylist[1].capabilitytype=SupportedLbIsolationservicecapabilitylist[1].capabilityvalue=dedicatedavailability=Optionalegresspolicy=ALLOWstate=Creatingstatus=Creatingallocationstate=CreatingsupportedServices=Dhcp,Dns,Firewall,Lb,SourceNat,StaticNat,PortForwarding,ConnectivityspecifyIpRanges=falsespecifyVlan=falseisPersistent=falseconservemode=falseserviceProviderList[0].service=DhcpserviceProviderList[0].provider=VirtualRouterserviceProviderList[1].service=DnsserviceProviderList[1].provider=VirtualRouterserviceProviderList[2].service=FirewallserviceProviderList[2].provider=VirtualRouterserviceProviderList[3].service=LbserviceProviderList[3].provider=VirtualRouterserviceProviderList[4].service=SourceNatserviceProviderList[4].provider=VirtualRouterserviceProviderList[5].service=StaticNatserviceProviderList[5].provider=VirtualRouterserviceProviderList[6].service=PortForwardingserviceProviderList[6].provider=VirtualRouterserviceProviderList[7].service=ConnectivityserviceProviderList[7].provider=Ovsegressdefaultpolicy=truetraffictype=GUEST Notice 'serviceProviderList[7].service=ConnectivityserviceProviderList[7].provider=Ovs' in the api fired. 2) in the list of network service providers on a physical network display OVS 3) enable OVS provider -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5429) KVM - Primary store down/Network Failure - Hosts attempt to reboot becasue of primary store being down hangs.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919520#comment-13919520 ] Marcus Sorensen commented on CLOUDSTACK-5429: - You could change from a clean reboot to sysrq triggers, which would be more like ipmi/power fencing that would normally occur in a situation like this. It's really bad to have VM processes running like this if we try to start them elsewhere. Most distributions enable it by default. It would be nice if the agent could also somehow tell the mgmt server that it's relinquishing those vms prior to force-rebooting itself, since I know under normal circumstances the HA VMs won't run anywhere else until the agent on this host is reachable again, which could be a long time if there's actually a host-specific issue. http://fedoraproject.org/wiki/QA/Sysrq KVM - Primary store down/Network Failure - Hosts attempt to reboot becasue of primary store being down hangs. - Key: CLOUDSTACK-5429 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5429 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: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: edison su Priority: Critical Fix For: 4.4.0 Attachments: kvm-networkshutdown.png, kvmhostreboot.png, psdown.rar KVM - Primary store down - Hosts attempt to reboot becasue of primary store being down hangs. Set up: Advanced zone with KVM (RHEL 6.3) hosts. Steps to reproduce the problem: 1. Deploy few Vms in each of the hosts with 10 GB ROOT volume size , so we start with 10 Vms. 2. Create snaposhot for ROOT volumes. 3. When snapshot is still in progress , Make the primary storage unavailable for 10 mts. This results in the KVM hosts to reboot. But reboot of KVM host is not successful. It is stuck at trying to unmount nfs mount points. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CLOUDSTACK-6181) Root resize
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919521#comment-13919521 ] Marcus Sorensen edited comment on CLOUDSTACK-6181 at 3/4/14 3:31 PM: - That brings up a good point. Hopefully people are aware that a template of 1G will still only have a 1G filesystem after this feature is deployed, regardless of root size. It just makes the disk bigger for extra partitions or resizing *filesystems* within the VM, and that should be pointed out in the feature info (if not already). Presumably admins could put an init script in their template to resize it after launch, if they wanted to do something like that. was (Author: mlsorensen): That brings up a good point. Hopefully people are aware that a template of 1G will still only have a 1G filesystem after this feature is deployed, regardless of root size. It just makes the disk bigger for extra partitions or resizing, and that should be pointed out in the feature info (if not already). Presumably admins could put an init script in their template to resize it after launch, if they wanted to do something like that. Root resize --- Key: CLOUDSTACK-6181 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6181 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Storage Controller, UI Affects Versions: 4.4.0 Environment: KVM/libvirt/CentOS, Xenserver Reporter: Nux Labels: disk, resize, template Fix For: 4.4.0 Rationale: Currently the root size of an instance is locked to that of the template. This creates unnecessary template duplicates, prevents the creation of a market place, wastes time and disk space and generally makes work more complicated. Real life example - a small VPS provider might want to offer the following sizes (in GB): 10,20,40,80,160,240,320,480,620 That's 9 offerings. The template selection could look like this, including real disk space used: Windows 2008 ~10GB Windows 2008+Plesk ~15GB Windows 2008+MSSQL ~15GB Windows 2012 ~10GB Windows 2012+Plesk ~15GB Windows 2012+MSSQL ~15GB CentOS ~1GB CentOS+CPanel ~3GB CentOS+Virtualmin ~3GB CentOS+Zimbra ~3GB CentOS+Docker ~2GB Debian ~1GB Ubuntu LTS ~1GB In this case the total disk space used by templates will be 828 GB, that's almost 1 TB. If your storage is expensive and limited SSD this can get painful! If the root resize feature is enabled we can reduce this to under 100 GB. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6181) Root resize
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919521#comment-13919521 ] Marcus Sorensen commented on CLOUDSTACK-6181: - That brings up a good point. Hopefully people are aware that a template of 1G will still only have a 1G filesystem after this feature is deployed, regardless of root size. It just makes the disk bigger for extra partitions or resizing, and that should be pointed out in the feature info (if not already). Presumably admins could put an init script in their template to resize it after launch, if they wanted to do something like that. Root resize --- Key: CLOUDSTACK-6181 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6181 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Storage Controller, UI Affects Versions: 4.4.0 Environment: KVM/libvirt/CentOS, Xenserver Reporter: Nux Labels: disk, resize, template Fix For: 4.4.0 Rationale: Currently the root size of an instance is locked to that of the template. This creates unnecessary template duplicates, prevents the creation of a market place, wastes time and disk space and generally makes work more complicated. Real life example - a small VPS provider might want to offer the following sizes (in GB): 10,20,40,80,160,240,320,480,620 That's 9 offerings. The template selection could look like this, including real disk space used: Windows 2008 ~10GB Windows 2008+Plesk ~15GB Windows 2008+MSSQL ~15GB Windows 2012 ~10GB Windows 2012+Plesk ~15GB Windows 2012+MSSQL ~15GB CentOS ~1GB CentOS+CPanel ~3GB CentOS+Virtualmin ~3GB CentOS+Zimbra ~3GB CentOS+Docker ~2GB Debian ~1GB Ubuntu LTS ~1GB In this case the total disk space used by templates will be 828 GB, that's almost 1 TB. If your storage is expensive and limited SSD this can get painful! If the root resize feature is enabled we can reduce this to under 100 GB. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6181) Root resize
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919550#comment-13919550 ] Nux commented on CLOUDSTACK-6181: - Marcus, For the CentOS cloud image hackaton at Fosdem I contributed an image (kickstart) that resizes the partition. It uses cloud-init and dracut-growroot. You can check it out here: http://li.nux.ro/download/cloudstack/ks/CentOS6_64bit_password_sshkey.ks Root resize --- Key: CLOUDSTACK-6181 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6181 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Storage Controller, UI Affects Versions: 4.4.0 Environment: KVM/libvirt/CentOS, Xenserver Reporter: Nux Labels: disk, resize, template Fix For: 4.4.0 Rationale: Currently the root size of an instance is locked to that of the template. This creates unnecessary template duplicates, prevents the creation of a market place, wastes time and disk space and generally makes work more complicated. Real life example - a small VPS provider might want to offer the following sizes (in GB): 10,20,40,80,160,240,320,480,620 That's 9 offerings. The template selection could look like this, including real disk space used: Windows 2008 ~10GB Windows 2008+Plesk ~15GB Windows 2008+MSSQL ~15GB Windows 2012 ~10GB Windows 2012+Plesk ~15GB Windows 2012+MSSQL ~15GB CentOS ~1GB CentOS+CPanel ~3GB CentOS+Virtualmin ~3GB CentOS+Zimbra ~3GB CentOS+Docker ~2GB Debian ~1GB Ubuntu LTS ~1GB In this case the total disk space used by templates will be 828 GB, that's almost 1 TB. If your storage is expensive and limited SSD this can get painful! If the root resize feature is enabled we can reduce this to under 100 GB. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-2692) [MIPN][Enhancement] Add load balancing support for MIPN
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy updated CLOUDSTACK-2692: -- Fix Version/s: (was: Future) 4.4.0 [MIPN][Enhancement] Add load balancing support for MIPN --- Key: CLOUDSTACK-2692 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2692 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.1.0, 4.2.0 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Fix For: 4.4.0 Add support of Load balancing for MIPN feature -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-4798) [Automation]Include the ability to get templates using keyword.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan updated CLOUDSTACK-4798: Assignee: (was: Sangeetha Hariharan) [Automation]Include the ability to get templates using keyword. --- Key: CLOUDSTACK-4798 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4798 Project: CloudStack Issue Type: Task Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.2.1 Reporter: Sangeetha Hariharan Fix For: 4.3.0 Currently get_template() call i common.py allows for getting template by ostype and template_id. It would be good to include the ability to get templates using keyword search.This will enable us to get a template by passing the name/partial name of the template. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CLOUDSTACK-6181) Root resize
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919550#comment-13919550 ] Nux edited comment on CLOUDSTACK-6181 at 3/4/14 4:41 PM: - Marcus, For the CentOS cloud image hackaton at Fosdem I contributed an image (kickstart) that resizes the partition. It uses cloud-init and dracut-growroot. You can check it out here: http://li.nux.ro/download/cloudstack/ks/CentOS6_64bit_password_sshkey.ks I will contribute tips to do the same for FreeBSD and Windows. was (Author: nuxro): Marcus, For the CentOS cloud image hackaton at Fosdem I contributed an image (kickstart) that resizes the partition. It uses cloud-init and dracut-growroot. You can check it out here: http://li.nux.ro/download/cloudstack/ks/CentOS6_64bit_password_sshkey.ks Root resize --- Key: CLOUDSTACK-6181 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6181 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Storage Controller, UI Affects Versions: 4.4.0 Environment: KVM/libvirt/CentOS, Xenserver Reporter: Nux Labels: disk, resize, template Fix For: 4.4.0 Rationale: Currently the root size of an instance is locked to that of the template. This creates unnecessary template duplicates, prevents the creation of a market place, wastes time and disk space and generally makes work more complicated. Real life example - a small VPS provider might want to offer the following sizes (in GB): 10,20,40,80,160,240,320,480,620 That's 9 offerings. The template selection could look like this, including real disk space used: Windows 2008 ~10GB Windows 2008+Plesk ~15GB Windows 2008+MSSQL ~15GB Windows 2012 ~10GB Windows 2012+Plesk ~15GB Windows 2012+MSSQL ~15GB CentOS ~1GB CentOS+CPanel ~3GB CentOS+Virtualmin ~3GB CentOS+Zimbra ~3GB CentOS+Docker ~2GB Debian ~1GB Ubuntu LTS ~1GB In this case the total disk space used by templates will be 828 GB, that's almost 1 TB. If your storage is expensive and limited SSD this can get painful! If the root resize feature is enabled we can reduce this to under 100 GB. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6198) VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk updated CLOUDSTACK-6198: -- Fix Version/s: (was: 4.4.0) 4.3.0 VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart --- Key: CLOUDSTACK-6198 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6198 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Blocker Fix For: 4.3.0 Regression bug. Steps to reproduce: 1. Create vpc and launch a vm in one tear. 2. vpc source ip address is from one subnet (ex: 10.147.52.1) 3. Acquire another public ip address from new public subnet. 4. create static nat on it to plug the nic on VR. 5. Now the VR has link local nic, guest nic, source nat ip nic and second public range nic. 6. Restart the vpc. 7. After restart there is no source nat nic. 8. If we restart vpc again observed that more nics are missed. I do observe the HUGE problem in 4.3 in VpcVirtualNetworkApplianceManager.java createVpcRouterNetworks() method. In 4.2 we used to store vm's nics in the ArrayList datastructure: ListPairNetworkVO, NicProfile networks = new ArrayListPairNetworkVO, NicProfile(4); ArrayList does allow duplicates. Then in 4.3 the datastructure was changed to LinkedHashMap that doesn't allow duplicates: LinkedHashMapNetwork, NicProfile networks = new LinkedHashMapNetwork, NicProfile(4); To fix the problem, the datastructure has to be changed to LinkedHashMapNetwork, ListNicProfile. It has to be changed all the way up to VirtualMachienManagerImpl where the nics are being passed to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6198) VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk reassigned CLOUDSTACK-6198: - Assignee: Alena Prokharchyk VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart --- Key: CLOUDSTACK-6198 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6198 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Blocker Fix For: 4.3.0 Regression bug. Steps to reproduce: 1. Create vpc and launch a vm in one tear. 2. vpc source ip address is from one subnet (ex: 10.147.52.1) 3. Acquire another public ip address from new public subnet. 4. create static nat on it to plug the nic on VR. 5. Now the VR has link local nic, guest nic, source nat ip nic and second public range nic. 6. Restart the vpc. 7. After restart there is no source nat nic. 8. If we restart vpc again observed that more nics are missed. I do observe the HUGE problem in 4.3 in VpcVirtualNetworkApplianceManager.java createVpcRouterNetworks() method. In 4.2 we used to store vm's nics in the ArrayList datastructure: ListPairNetworkVO, NicProfile networks = new ArrayListPairNetworkVO, NicProfile(4); ArrayList does allow duplicates. Then in 4.3 the datastructure was changed to LinkedHashMap that doesn't allow duplicates: LinkedHashMapNetwork, NicProfile networks = new LinkedHashMapNetwork, NicProfile(4); To fix the problem, the datastructure has to be changed to LinkedHashMapNetwork, ListNicProfile. It has to be changed all the way up to VirtualMachienManagerImpl where the nics are being passed to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6181) Root resize
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919802#comment-13919802 ] Mike Tutkowski commented on CLOUDSTACK-6181: Hi, I am working on an improvement to managed storage for 4.4 that will enable users to have guaranteed storage Quality of Service for root disks. I can add this root resize to my test matrix for 4.4. Of hand, I don't see any problem supporting it. Thanks, Mike Root resize --- Key: CLOUDSTACK-6181 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6181 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Storage Controller, UI Affects Versions: 4.4.0 Environment: KVM/libvirt/CentOS, Xenserver Reporter: Nux Labels: disk, resize, template Fix For: 4.4.0 Rationale: Currently the root size of an instance is locked to that of the template. This creates unnecessary template duplicates, prevents the creation of a market place, wastes time and disk space and generally makes work more complicated. Real life example - a small VPS provider might want to offer the following sizes (in GB): 10,20,40,80,160,240,320,480,620 That's 9 offerings. The template selection could look like this, including real disk space used: Windows 2008 ~10GB Windows 2008+Plesk ~15GB Windows 2008+MSSQL ~15GB Windows 2012 ~10GB Windows 2012+Plesk ~15GB Windows 2012+MSSQL ~15GB CentOS ~1GB CentOS+CPanel ~3GB CentOS+Virtualmin ~3GB CentOS+Zimbra ~3GB CentOS+Docker ~2GB Debian ~1GB Ubuntu LTS ~1GB In this case the total disk space used by templates will be 828 GB, that's almost 1 TB. If your storage is expensive and limited SSD this can get painful! If the root resize feature is enabled we can reduce this to under 100 GB. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6192) KVM: StartCommand and PrepareForMigrationCommand don't fail if storage adaptor fails connectPhysicalDisk
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920033#comment-13920033 ] ASF subversion and git services commented on CLOUDSTACK-6192: - Commit fb0b2eb26731a6db00c65dcd799653a213475387 in cloudstack's branch refs/heads/master from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fb0b2eb ] CLOUDSTACK-6192: Return failure on StartCommand and PrepareForMigrationCommand when connectPhysicalDisk fails, rather than continuing on KVM: StartCommand and PrepareForMigrationCommand don't fail if storage adaptor fails connectPhysicalDisk Key: CLOUDSTACK-6192 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6192 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0, 4.4.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Priority: Minor Fix For: 4.4.0 PrepareForMigrationCommand returns success even if the disks are not properly prepared (storage adaptor returns false to connectPhysicalDisk). Likewise, StartCommand continues on with trying to start the VM if connectPhysicalDisk fails. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6192) KVM: StartCommand and PrepareForMigrationCommand don't fail if storage adaptor fails connectPhysicalDisk
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920044#comment-13920044 ] ASF subversion and git services commented on CLOUDSTACK-6192: - Commit fb0b2eb26731a6db00c65dcd799653a213475387 in cloudstack's branch refs/heads/resize-root from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fb0b2eb ] CLOUDSTACK-6192: Return failure on StartCommand and PrepareForMigrationCommand when connectPhysicalDisk fails, rather than continuing on KVM: StartCommand and PrepareForMigrationCommand don't fail if storage adaptor fails connectPhysicalDisk Key: CLOUDSTACK-6192 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6192 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0, 4.4.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Priority: Minor Fix For: 4.4.0 PrepareForMigrationCommand returns success even if the disks are not properly prepared (storage adaptor returns false to connectPhysicalDisk). Likewise, StartCommand continues on with trying to start the VM if connectPhysicalDisk fails. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6199) Action Events - hide them when display flag is off in the context of Ability to have better control over first class objects in CS feature
Nitin Mehta created CLOUDSTACK-6199: --- Summary: Action Events - hide them when display flag is off in the context of Ability to have better control over first class objects in CS feature Key: CLOUDSTACK-6199 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6199 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: 4.4.0 Action Events - hide them when display flag is off in the context of Ability to have better control over first class objects in CS feature. For root admin - s/he should be able to see all the events despite the value of the flag. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6199) Action Events - hide them when display flag is off in the context of Ability to have better control over first class objects in CS feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920164#comment-13920164 ] ASF subversion and git services commented on CLOUDSTACK-6199: - Commit 339c4f4c3fb4f50e58b780893b16be192f985d82 in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=339c4f4 ] CLOUDSTACK-6199: Action Events - hide them when display flag is off in the context of Ability to have better control over first class objects in CS feature. For root admin - s/he should be able to see all the events despite the value of the flag. Action Events - hide them when display flag is off in the context of Ability to have better control over first class objects in CS feature Key: CLOUDSTACK-6199 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6199 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: 4.4.0 Action Events - hide them when display flag is off in the context of Ability to have better control over first class objects in CS feature. For root admin - s/he should be able to see all the events despite the value of the flag. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5872) Async response from addAccountToProject doesn't contain useful information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920216#comment-13920216 ] ASF subversion and git services commented on CLOUDSTACK-5872: - Commit 444e8f6bb3447a7eeb97f7c5d9b46abba3150072 in cloudstack's branch refs/heads/4.3-forward from [~alena1108] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=444e8f6 ] CLOUDSTACK-5872: use List DS for storing NicProfiles as public network can have more than one nic Async response from addAccountToProject doesn't contain useful information -- Key: CLOUDSTACK-5872 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5872 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Reporter: Bill Jones Assignee: David Grizzanti Fix For: 4.4.0 Attachments: unnamed.patch The async response from addAccountToProject doesn't contain useful information. Generally async responses for commands that modify resources include the resource ID and/or description in the async response. This is not true of addAccountToProject or deleteAccountFromProject. Consequently the response is not so useful to clients that do not have access to the context of the request. Also, it seems inconsistent with the general design of the API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5872) Async response from addAccountToProject doesn't contain useful information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920219#comment-13920219 ] Alena Prokharchyk commented on CLOUDSTACK-5872: --- Ignore my last commit as it relates to some other bug. Async response from addAccountToProject doesn't contain useful information -- Key: CLOUDSTACK-5872 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5872 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Reporter: Bill Jones Assignee: David Grizzanti Fix For: 4.4.0 Attachments: unnamed.patch The async response from addAccountToProject doesn't contain useful information. Generally async responses for commands that modify resources include the resource ID and/or description in the async response. This is not true of addAccountToProject or deleteAccountFromProject. Consequently the response is not so useful to clients that do not have access to the context of the request. Also, it seems inconsistent with the general design of the API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6198) VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920227#comment-13920227 ] Alena Prokharchyk commented on CLOUDSTACK-6198: --- Fixed in master and 4.3 forward with commit 444e8f6bb3447a7eeb97f7c5d9b46abba3150072. VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart --- Key: CLOUDSTACK-6198 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6198 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Blocker Fix For: 4.3.0 Regression bug. Steps to reproduce: 1. Create vpc and launch a vm in one tear. 2. vpc source ip address is from one subnet (ex: 10.147.52.1) 3. Acquire another public ip address from new public subnet. 4. create static nat on it to plug the nic on VR. 5. Now the VR has link local nic, guest nic, source nat ip nic and second public range nic. 6. Restart the vpc. 7. After restart there is no source nat nic. 8. If we restart vpc again observed that more nics are missed. I do observe the HUGE problem in 4.3 in VpcVirtualNetworkApplianceManager.java createVpcRouterNetworks() method. In 4.2 we used to store vm's nics in the ArrayList datastructure: ListPairNetworkVO, NicProfile networks = new ArrayListPairNetworkVO, NicProfile(4); ArrayList does allow duplicates. Then in 4.3 the datastructure was changed to LinkedHashMap that doesn't allow duplicates: LinkedHashMapNetwork, NicProfile networks = new LinkedHashMapNetwork, NicProfile(4); To fix the problem, the datastructure has to be changed to LinkedHashMapNetwork, ListNicProfile. It has to be changed all the way up to VirtualMachienManagerImpl where the nics are being passed to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6198) VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920224#comment-13920224 ] ASF subversion and git services commented on CLOUDSTACK-6198: - Commit 5a8d165afae7b5e6add7732f5d18fa3a37d7c230 in cloudstack's branch refs/heads/master from [~alena1108] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5a8d165 ] CLOUDSTACK-6198: use List DS for storing NicProfiles as public network can have more than one nic Conflicts: engine/api/src/com/cloud/vm/VirtualMachineManager.java engine/api/src/org/apache/cloudstack/engine/orchestration/service/NetworkOrchestrationService.java engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java engine/orchestration/src/org/apache/cloudstack/engine/orchestration/CloudOrchestrator.java engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java plugins/network-elements/elastic-loadbalancer/src/com/cloud/network/lb/ElasticLoadBalancerManagerImpl.java plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManagerImpl.java plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServiceManagerImpl.java server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java server/test/com/cloud/vpc/MockNetworkManagerImpl.java services/secondary-storage/controller/src/org/apache/cloudstack/secondarystorage/SecondaryStorageManagerImpl.java VPC: secondary public ip address (from diff Vlan range) doesn't get reprogrammed on the VR upon VPC/Network/VR resetart --- Key: CLOUDSTACK-6198 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6198 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Blocker Fix For: 4.3.0 Regression bug. Steps to reproduce: 1. Create vpc and launch a vm in one tear. 2. vpc source ip address is from one subnet (ex: 10.147.52.1) 3. Acquire another public ip address from new public subnet. 4. create static nat on it to plug the nic on VR. 5. Now the VR has link local nic, guest nic, source nat ip nic and second public range nic. 6. Restart the vpc. 7. After restart there is no source nat nic. 8. If we restart vpc again observed that more nics are missed. I do observe the HUGE problem in 4.3 in VpcVirtualNetworkApplianceManager.java createVpcRouterNetworks() method. In 4.2 we used to store vm's nics in the ArrayList datastructure: ListPairNetworkVO, NicProfile networks = new ArrayListPairNetworkVO, NicProfile(4); ArrayList does allow duplicates. Then in 4.3 the datastructure was changed to LinkedHashMap that doesn't allow duplicates: LinkedHashMapNetwork, NicProfile networks = new LinkedHashMapNetwork, NicProfile(4); To fix the problem, the datastructure has to be changed to LinkedHashMapNetwork, ListNicProfile. It has to be changed all the way up to VirtualMachienManagerImpl where the nics are being passed to. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6199) Action Events - hide them when display flag is off in the context of Ability to have better control over first class objects in CS feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920404#comment-13920404 ] ASF subversion and git services commented on CLOUDSTACK-6199: - Commit f291951990fbf0c51c2e9aa95d246d73e8abde8b in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f291951 ] CLOUDSTACK-6199: Add the column display_event to event table ~ Action Events - hide them when display flag is off in the context of Ability to have better control over first class objects in CS feature Key: CLOUDSTACK-6199 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6199 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: 4.4.0 Action Events - hide them when display flag is off in the context of Ability to have better control over first class objects in CS feature. For root admin - s/he should be able to see all the events despite the value of the flag. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6103) vms with isos attached don't migrate
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920420#comment-13920420 ] Animesh Chaturvedi commented on CLOUDSTACK-6103: Marcus, does this need to be pulled in for 4.3 or can wait for 4.4 vms with isos attached don't migrate Key: CLOUDSTACK-6103 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6103 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0, Future, 4.3.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.3.0, 4.4.0 VMs with isos attached don't seem to provide the iso information with PrepareForMigrationCommand. This seems to be hypervisor-agnostic, though not all hypervisors may require it to be passed in preparation. Commit incoming... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-5355) addImageStore should not log password in clear text in the log
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sowmya Krishnan closed CLOUDSTACK-5355. --- Verified with cifs addImageStore should not log password in clear text in the log -- Key: CLOUDSTACK-5355 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5355 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Sowmya Krishnan Assignee: Min Chen Priority: Critical Fix For: 4.3.0 For cifs, addImageStore are currently logging everything including username, password and domain in clear text in the logs, which are specified in query parameter url for the image store. Here's an extract from the logs: (obscured actual pwd) 2013-11-26 12:03:35,703 DEBUG [c.c.a.ApiServlet] (catalina-exec-13:ctx-f0723f52) ===START=== 10.104.255.45 – GET command=addImageStoreresponse=jsonsessionkey=5DGP7gv1vXNaK35rAxfIEi7256o%3Dname=SS1provider=SMBzoneid=5a60af2b-3025-4f2a-9ecc-8e33bf2b94e3url=cifs%3A%2F%2F10.102.192.150%2FSMB-Share%2Fsowmya%2Fsecondary%3Fuser%3Dsowmya%26password%3DX%40123%26domain%3DBLR_=1385447356899 2013-11-26 12:03:35,741 INFO [o.a.c.s.d.l.CloudStackImageStoreLifeCycleImpl] (catalina-exec-13:ctx-f0723f52 ctx-547cfc1f) Trying to add a new data store at cifs://10.102.192.150/SMB-Share/sowmya/secondary?user=sowmyapassword=XXX@123domain=BLR to data center 1 2013-11-26 12:03:35,776 DEBUG [c.c.u.UriUtils] (catalina-exec-13:ctx-f0723f52 ctx-547cfc1f) foundUser istrue 2013-11-26 12:03:35,777 DEBUG [c.c.u.UriUtils] (catalina-exec-13:ctx-f0723f52 ctx-547cfc1f) foundPswd istrue 2013-11-26 12:03:36,011 DEBUG [c.c.a.ApiServlet] (catalina-exec-13:ctx-f0723f52 ctx-547cfc1f) ===END=== 10.104.255.45 – GET command=addImageStoreresponse=jsonsessionkey=5DGP7gv1vXNaK35rAxfIEi7256o%3Dname=SS1provider=SMBzoneid=5a60af2b-3025-4f2a-9ecc-8e33bf2b94e3url=cifs%3A%2F%2F10.102.192.150%2FSMB-Share%2Fsowmya%2Fsecondary%3Fuser%3Dsowmya%26password%3DXXX%40123%26domain%3DBLR_=1385447356899 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6103) vms with isos attached don't migrate
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920494#comment-13920494 ] Marcus Sorensen commented on CLOUDSTACK-6103: - If there is opportunity to... vms with isos attached don't migrate Key: CLOUDSTACK-6103 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6103 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0, Future, 4.3.0 Reporter: Marcus Sorensen Assignee: Marcus Sorensen Fix For: 4.3.0, 4.4.0 VMs with isos attached don't seem to provide the iso information with PrepareForMigrationCommand. This seems to be hypervisor-agnostic, though not all hypervisors may require it to be passed in preparation. Commit incoming... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6194) Failed to increase Shared network IP Range
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920517#comment-13920517 ] ASF subversion and git services commented on CLOUDSTACK-6194: - Commit b8413b9413eb39053c378309195469a4d5d4fec0 in cloudstack's branch refs/heads/master from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b8413b9 ] CLOUDSTACK-6194: Failed to increase Shared network IP Range Submitted-by:Saksham Srivastava saksham.srivast...@citrix.com Failed to increase Shared network IP Range -- Key: CLOUDSTACK-6194 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6194 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.3.0 Environment: Xenserver, CloudStack 4.3-forward Reporter: Saksham Srivastava Assignee: Saksham Srivastava Fix For: 4.3.0 Steps from UI: 1. Newly installed setup with Adv zone configuration 2. Created shared network 3. Tried to Add IP range to the same shared network. Observation: It failed saying there is already one vlan 110 on network :212, only one vlan is allowed on guest network . -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6194) Failed to increase Shared network IP Range
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920519#comment-13920519 ] ASF subversion and git services commented on CLOUDSTACK-6194: - Commit cd0d16f05a2be02e3de1a327bba9a5acd112e4f2 in cloudstack's branch refs/heads/4.3-forward from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cd0d16f ] CLOUDSTACK-6194: Failed to increase Shared network IP Range Submitted-by:Saksham Srivastava saksham.srivast...@citrix.com Failed to increase Shared network IP Range -- Key: CLOUDSTACK-6194 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6194 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.3.0 Environment: Xenserver, CloudStack 4.3-forward Reporter: Saksham Srivastava Assignee: Saksham Srivastava Fix For: 4.3.0 Steps from UI: 1. Newly installed setup with Adv zone configuration 2. Created shared network 3. Tried to Add IP range to the same shared network. Observation: It failed saying there is already one vlan 110 on network :212, only one vlan is allowed on guest network . -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-5535) Do not allow addNetwork to create NIC across VPC tiers and Isolated Networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti closed CLOUDSTACK-5535. based on review closing Do not allow addNetwork to create NIC across VPC tiers and Isolated Networks - Key: CLOUDSTACK-5535 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5535 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.3.0 Reporter: Saksham Srivastava Assignee: Saksham Srivastava Priority: Critical Fix For: 4.3.0 addNetworkToVM allows adding any network to VM. Ideally a VM running in isolated Guest Network should not be able to add a VPC tier. A VM running in VPC tier should not be allowed to add another tier A VM running in VPC tier should not be allowed to add another isolated guest network. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-4997) OVS integration is broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti closed CLOUDSTACK-4997. OVS integration is broken - Key: CLOUDSTACK-4997 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4997 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: Murali Reddy Assignee: Murali Reddy Fix For: 4.3.0 OVS integration is broken as network orchestrator will not consult a network element unless its a service provider for a service in the network offering. Prior to 4.2, network orchestrator will blindly loop through all network elements so OVS functionality for GRE overlays used to work. this bug is to make OVS integration work by making it as service provider for 'Connectivity' service. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-3252) An instance deployed using explicit or implicit dedication doesn't generate a usage event
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti resolved CLOUDSTACK-3252. -- Resolution: Fixed An instance deployed using explicit or implicit dedication doesn't generate a usage event - Key: CLOUDSTACK-3252 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3252 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: Devdeep Singh Assignee: Saksham Srivastava Fix For: 4.3.0 If an instance is deployed using explicit or implicit dedication, or neither of them a usage event isn't generated. It'll be good to have a VM usage event generated so that someone looking at the usage logs can use this information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-5295) [Automation] Router deployment failed with null pointer exception, while calling VirtualNetworkApplianceManagerImpl.getVpnCidr
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti closed CLOUDSTACK-5295. based on earlier comment and no action taken, closing it. Pl open if this happens again [Automation] Router deployment failed with null pointer exception, while calling VirtualNetworkApplianceManagerImpl.getVpnCidr --- Key: CLOUDSTACK-5295 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5295 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Assignee: Sheng Yang Priority: Blocker Fix For: 4.3.0 Attachments: agent1.rar, agent2.rar, management-server.log.2013-11-26.gz, management-server.rar This issue observed in autoamtion environment; many router deployment failed below error 2013-11-27 02:34:02,194 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Sending network shutdown to VirtualRouter 2013-11-27 02:34:02,196 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Stopping router VM[DomainRouter|r-586-QA] 2013-11-27 02:34:02,198 DEBUG [c.c.v.VirtualMachineManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) VM is already stopped: VM[DomainRouter|r-586-QA] 2013-11-27 02:34:02,200 DEBUG [c.c.a.ApiServlet] (catalina-exec-7:ctx-436ed958) ===START=== 10.223.240.194 -- GET signature=DFJW4CnPHf9BbR%2BTYevb%2FA8%2BZpM%3DapiKey=1fASWWJnTkiQdjWWd9ex6s pm2-D7xsAQvkXh8vBMHIay-aW6dYeUqWsBoAcK-jkfQKPvBaDJLQDEDra4cfGfaAcommand=queryAsyncJobResultresponse=jsonjobid=cb269b12-6c73-44dd-82aa-1303bf3d33fb 2013-11-27 02:34:02,204 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Network id=489 is shutdown successfully, cleaning up corresponding resources now. 2013-11-27 02:34:02,209 DEBUG [c.c.n.g.GuestNetworkGuru] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Releasing vnet for the network id=489 2013-11-27 02:34:02,221 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Lock is released for network Ntwk[489|Guest|8] as a part of network shutdown 2013-11-27 02:34:02,222 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Lock is released for network id 489 as a part of network implement 2013-11-27 02:34:02,222 INFO [c.c.v.VirtualMachineManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Unable to contact resource. com.cloud.exception.AgentUnavailableException: Resource [Host:2] is unreachable: Host 2: Unable to start instance due to null at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1011) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2667) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:1767) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:1867) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1845) at sun.reflect.GeneratedMethodAccessor300.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetwork(NetworkOrchestrator.java:960) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1222) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:899) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:552) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3465) at
[jira] [Reopened] (CLOUDSTACK-3252) An instance deployed using explicit or implicit dedication doesn't generate a usage event
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti reopened CLOUDSTACK-3252: -- An instance deployed using explicit or implicit dedication doesn't generate a usage event - Key: CLOUDSTACK-3252 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3252 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: Devdeep Singh Assignee: Saksham Srivastava Fix For: 4.3.0 If an instance is deployed using explicit or implicit dedication, or neither of them a usage event isn't generated. It'll be good to have a VM usage event generated so that someone looking at the usage logs can use this information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-5343) Volume limit applied to project/account does not count root disks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti closed CLOUDSTACK-5343. Reopen if this happens again Volume limit applied to project/account does not count root disks - Key: CLOUDSTACK-5343 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5343 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Prachi Damle Fix For: 4.3.0 1. Create any project or account. 2. Set the volume limit as 1. 3. Deploy an instance without data disk in project/account. 4. Now you can see the root disk in the volumes, but if you list the account/project, then the volume count still shows as 0. 5. Now add new data disk. 6. Check volume count, now it shows it as 1 (But it should have shown as 2, and it should have failed at this stage only saying limit exceeded.) 7. Add another data disk (Now it will fail) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-4676) [Baremetal] baremetal hostename should not be fixed in kickstart file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-4676: - Fix Version/s: (was: 4.3.0) [Baremetal] baremetal hostename should not be fixed in kickstart file Key: CLOUDSTACK-4676 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4676 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: angeline shen Assignee: frank zhang since baremetal hostname is fixed in kickstart file, if baremetal server choose same template, hostnames are all the same. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CLOUDSTACK-4676) [Baremetal] baremetal hostename should not be fixed in kickstart file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti reopened CLOUDSTACK-4676: -- [Baremetal] baremetal hostename should not be fixed in kickstart file Key: CLOUDSTACK-4676 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4676 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: angeline shen Assignee: frank zhang since baremetal hostname is fixed in kickstart file, if baremetal server choose same template, hostnames are all the same. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6200) [Automation] Add support for Hyper-v in regression test test_routers.py
Sanjeev N created CLOUDSTACK-6200: - Summary: [Automation] Add support for Hyper-v in regression test test_routers.py Key: CLOUDSTACK-6200 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6200 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: Cloudstack 4.3 Advanced zone with Hyper-v Reporter: Sanjeev N Fix For: 4.3.0 [Automation] Add support for Hyper-v in regression test test_routers.py test inside class TestRouterStopCreateFW checks for dnsmasq services status inside VR. at line no: 1270. Following is the code to verify it: 1269 # For DNS and DHCP check 'dnsmasq' process status 1270 if self.apiclient.hypervisor.lower() == 'vmware': 1271result = get_process_status( 1272self.apiclient.connection.mgtSvr, 127322, 1274self.apiclient.connection.user, 1275self.apiclient.connection.passwd, 1276router.linklocalip, 1277'iptables -t nat -L', 1278 hypervisor=self.apiclient.hypervisor 1279) 1280 else: 1281 try: 1282 result = get_process_status( 1283 host.ipaddress, 1284 22, 1285 host.user, 1286 host.passwd, 1287 router.linklocalip, 1288 'iptables -t nat -L' 1289 ) 1290 except KeyError: 1291 self.skipTest(Provide a marvin config file with host credentials to run %s % self._testMethodName) This code will work for vmware, xen and kvm but not for Hyper-v. So need to add support for Hyper-v as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6200) [Automation] Add support for Hyper-v in regression test test_routers.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N closed CLOUDSTACK-6200. - Resolution: Invalid [Automation] Add support for Hyper-v in regression test test_routers.py --- Key: CLOUDSTACK-6200 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6200 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: Cloudstack 4.3 Advanced zone with Hyper-v Reporter: Sanjeev N Labels: automation Fix For: 4.3.0 [Automation] Add support for Hyper-v in regression test test_routers.py test inside class TestRouterStopCreateFW checks for dnsmasq services status inside VR. at line no: 1270. Following is the code to verify it: 1269 # For DNS and DHCP check 'dnsmasq' process status 1270 if self.apiclient.hypervisor.lower() == 'vmware': 1271result = get_process_status( 1272self.apiclient.connection.mgtSvr, 127322, 1274self.apiclient.connection.user, 1275self.apiclient.connection.passwd, 1276router.linklocalip, 1277'iptables -t nat -L', 1278 hypervisor=self.apiclient.hypervisor 1279) 1280 else: 1281 try: 1282 result = get_process_status( 1283 host.ipaddress, 1284 22, 1285 host.user, 1286 host.passwd, 1287 router.linklocalip, 1288 'iptables -t nat -L' 1289 ) 1290 except KeyError: 1291 self.skipTest(Provide a marvin config file with host credentials to run %s % self._testMethodName) This code will work for vmware, xen and kvm but not for Hyper-v. So need to add support for Hyper-v as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-5728) [Automation] ReplaceNetworkACLListCmd command failing with NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-5728: Fix Version/s: (was: 4.3.0) 4.4.0 [Automation] ReplaceNetworkACLListCmd command failing with NPE -- Key: CLOUDSTACK-5728 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5728 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.3.0 Environment: KVM and vmware branch 4.3 Reporter: Rayees Namathponnan Assignee: Jayapal Reddy Priority: Blocker Fix For: 4.4.0 Attachments: management-server.rar BVT test case test_privategw_acl.TestPrivateGwACL.test_privategw_acl failing with NPE, this failure observed from Dec 27th on words Test case performing below steps # 1) Create VPC # 2) Create ACl # 3) Create ACl Item # 4) Create network with ACL # 6) update acl id Observed below error 7577-47b5-bb33-db9f8c542de0,httpmethod:GET,ctxAccountId:2,ctxStartEventId:1063,apiKey:EHF5nlA7E3UW18UHPpnUOrB1KScPXUdMPFtCl8t7tNc2k_1n0ZkD0Tv-X8Lp9OXMy4uPGReYq3R9q2ddkIb-2g,signature:vIdDK7TNp5mRqcgsEs+m3lGSdjc\u 003d}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid: 29066118877352, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2014-01-02 14:14:51,316 DEBUG [c.c.a.ApiServlet] (catalina-exec-18:ctx-607621af ctx-a91ea8f3 ctx-6baa9395) ===END=== 10.223.240.194 -- GET apiKey=EHF5nlA7E3UW18UHPpnUOrB1KScPXUdMPFtCl8t7tNc2k_1n0ZkD0Tv-X8Lp9OXMy4uPGReYq3R9q2ddkIb- 2gaclid=5db946bd-d5a2-47bd-8dda-1653c21b2af5command=replaceNetworkACLListsignature=vIdDK7TNp5mRqcgsEs%2Bm3lGSdjc%3Dgatewayid=a51a8831-7577-47b5-bb33-db9f8c542de0response=json 2014-01-02 14:14:51,320 DEBUG [c.c.a.ApiServlet] (catalina-exec-17:ctx-a8650844) ===START=== 10.223.240.194 -- GET signature=Im99pBFJIOBuch6mHvf4WilMbwU%3DapiKey=EHF5nlA7E3UW18UHPpnUOrB1KScPXUdMPFtCl8t7tNc2k_1n0ZkD0Tv-X8Lp9OXMy4u PGReYq3R9q2ddkIb-2gcommand=queryAsyncJobResultresponse=jsonjobid=e9391f75-b3ee-4255-8bc7-5439dd7ba68f 2014-01-02 14:14:51,341 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (Job-Executor-1:ctx-f84f626a ctx-6baa9395) Applying network acls in network Ntwk[239|Guest|5] 2014-01-02 14:14:51,346 DEBUG [c.c.a.ApiServlet] (catalina-exec-17:ctx-a8650844 ctx-36cff002 ctx-0b21bcc7) ===END=== 10.223.240.194 -- GET signature=Im99pBFJIOBuch6mHvf4WilMbwU%3DapiKey=EHF5nlA7E3UW18UHPpnUOrB1KScPXUdMPFtCl8t7tNc 2k_1n0ZkD0Tv-X8Lp9OXMy4uPGReYq3R9q2ddkIb-2gcommand=queryAsyncJobResultresponse=jsonjobid=e9391f75-b3ee-4255-8bc7-5439dd7ba68f 2014-01-02 14:14:51,364 ERROR [c.c.a.ApiAsyncJobDispatcher] (Job-Executor-1:ctx-f84f626a) Unexpected exception while executing org.apache.cloudstack.api.command.user.network.ReplaceNetworkACLListCmd java.lang.NullPointerException at com.cloud.hypervisor.HypervisorGuruBase.toNicTO(HypervisorGuruBase.java:60) at com.cloud.vm.VirtualMachineManagerImpl.toNicTO(VirtualMachineManagerImpl.java:3212) at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.getNicTO(VpcVirtualNetworkApplianceManagerImpl.java:489) at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.createNetworkACLsCommands(VpcVirtualNetworkApplianceManagerImpl.java:699) at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.sendNetworkACLs(VpcVirtualNetworkApplianceManagerImpl.java:673) at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl$2.execute(VpcVirtualNetworkApplianceManagerImpl.java:665) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3738) at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.applyNetworkACLs(VpcVirtualNetworkApplianceManagerImpl.java:662) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at
[jira] [Created] (CLOUDSTACK-6201) createVMSnapshot doesn't check volume state
Qian Shaohua created CLOUDSTACK-6201: Summary: createVMSnapshot doesn't check volume state Key: CLOUDSTACK-6201 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6201 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.3.0 Reporter: Qian Shaohua We meet the follow case in 4.2.1: 1. deploy a vm 2. stop it 3. restore it, ROOT volume is allocated. 4. create vm snapshot Step 4 should always fail, but a createVMSnapshot job is still created without checking volume state. CreateVMSnapshot api call should fail immediately in this case. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6162) support OVS as connectivity service provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920619#comment-13920619 ] ASF subversion and git services commented on CLOUDSTACK-6162: - Commit e9a3d412850c86b21b8d8b8be373a57a132c0312 in cloudstack's branch refs/heads/4.3 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e9a3d41 ] CLOUDSTACK-6162: UI zone physical network service provider OVS match provider name Ovs in listNetworkServiceProviders API response. (cherry picked from commit 930acdde3d9c9a6ef1db90ae2f6ba3a9d8f15959) Signed-off-by: Animesh Chaturvedi anim...@apache.org support OVS as connectivity service provider Key: CLOUDSTACK-6162 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6162 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.3.0 Attachments: jessica-2014-02-25.PNG, jessica-2014-02-25B.PNG Below UI changes are needed to enable OVS as connectivity provider while creating network offering. Below changes are required: 1) In the drop down box for 'Connectivity' service provider in the network offering dialog box, expose Ovs as provider. And corresponding API call would be: http://192.168.20.112:8080/client/api?command=createNetworkOfferingsessionkey=0YutiBb19VkXgepJYf/wq2Wii4Q=name=ovs-connectivity-offeringdisplayText=ovs-connectivity-offeringguestIpType=IsolatedlbType=publicLbservicecapabilitylist[0].service=SourceNatservicecapabilitylist[0].capabilitytype=SupportedSourceNatTypesservicecapabilitylist[0].capabilityvalue=peraccountservicecapabilitylist[1].service=lbservicecapabilitylist[1].capabilitytype=SupportedLbIsolationservicecapabilitylist[1].capabilityvalue=dedicatedavailability=Optionalegresspolicy=ALLOWstate=Creatingstatus=Creatingallocationstate=CreatingsupportedServices=Dhcp,Dns,Firewall,Lb,SourceNat,StaticNat,PortForwarding,ConnectivityspecifyIpRanges=falsespecifyVlan=falseisPersistent=falseconservemode=falseserviceProviderList[0].service=DhcpserviceProviderList[0].provider=VirtualRouterserviceProviderList[1].service=DnsserviceProviderList[1].provider=VirtualRouterserviceProviderList[2].service=FirewallserviceProviderList[2].provider=VirtualRouterserviceProviderList[3].service=LbserviceProviderList[3].provider=VirtualRouterserviceProviderList[4].service=SourceNatserviceProviderList[4].provider=VirtualRouterserviceProviderList[5].service=StaticNatserviceProviderList[5].provider=VirtualRouterserviceProviderList[6].service=PortForwardingserviceProviderList[6].provider=VirtualRouterserviceProviderList[7].service=ConnectivityserviceProviderList[7].provider=Ovsegressdefaultpolicy=truetraffictype=GUEST Notice 'serviceProviderList[7].service=ConnectivityserviceProviderList[7].provider=Ovs' in the api fired. 2) in the list of network service providers on a physical network display OVS 3) enable OVS provider -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6187) Migrate router from UI is showing error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920621#comment-13920621 ] ASF subversion and git services commented on CLOUDSTACK-6187: - Commit a1000b99ff5e91cac8c8d1a70a51f09b0850d2a8 in cloudstack's branch refs/heads/4.3 from Jayapal [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a1000b9 ] CLOUDSTACK-6187: Fixed MigrateSystemVMCmd response for router (cherry picked from commit 37ce4e52c28081a0c718ca87fdbff79935074b75) Signed-off-by: Animesh Chaturvedi anim...@apache.org Migrate router from UI is showing error --- Key: CLOUDSTACK-6187 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6187 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.3.0 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Fix For: 4.3.0, 4.4.0 1. Migrate router from the UI is showing error. Migration of router happened successfully but the listRouters api is showing error. 2. This issue is because MigrateSystemVMCmd api response systemvm property is empty. 2014-02-03 10:36:05,363 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-32:ctx-6d049390) Done executing com.cloud.vm.VmWorkMigrate for job-53 2014-02-03 10:36:05,400 DEBUG [o.a.c.f.j.i.SyncQueueManagerImpl] (Job-Executor-32:ctx-6d049390) Sync queue (3) is currently empty 2014-02-03 10:36:05,401 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-32:ctx-6d049390) Remove job-53 from job monitoring 2014-02-03 10:36:07,950 DEBUG [c.c.a.ApiServlet] (catalina-exec-4:ctx-4c128982) ===START=== 10.252.192.25 – GET command=queryAsyncJobResultjobId=f939d9f6-7ba0-47fe-ov8%3D_=1391422430324 2014-02-03 10:36:07,987 DEBUG [c.c.a.ApiServlet] (catalina-exec-4:ctx-4c128982 ctx-a4265f7b) ===END=== 10.252.192.25 – GET command=queryAsyncJobResultjobId=f939d9f6vFwGfRH%2Brov8%3D_=1391422430324 2014-02-03 10:36:08,157 DEBUG [c.c.a.ApiServlet] (catalina-exec-19:ctx-7627cfac) ===START=== 10.252.192.25 – GET command=listRoutersid=undefinedresponse=jsonsessi 2014-02-03 10:36:08,172 DEBUG [c.c.a.ApiDispatcher] (catalina-exec-19:ctx-7627cfac ctx-28964964) Object entity uuid = undefined does not exist in the database. 2014-02-03 10:36:08,172 INFO [c.c.a.ApiServer] (catalina-exec-19:ctx-7627cfac ctx-28964964) Unable to execute API command listrouters due to invalid value. Invalid party does not exist or due to incorrect parameter annotation for the field in api cmd class. 2014-02-03 10:36:08,174 DEBUG [c.c.a.ApiServlet] (catalina-exec-19:ctx-7627cfac ctx-28964964) ===END=== 10.252.192.25 – GET command=listRoutersid=undefinedresponse -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6183) Unplug the nic when all the ips of public subnet is released
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920620#comment-13920620 ] ASF subversion and git services commented on CLOUDSTACK-6183: - Commit 86643d6e3fd3261cabe105a452e33017a77a23e3 in cloudstack's branch refs/heads/4.3 from Jayapal [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=86643d6 ] CLOUDSTACK-6183: unplug the nic when all the ips of public vlan range is removed (cherry picked from commit 7700a1b71622c1d45b2b54aa7444be5adc4fb8ab) Signed-off-by: Animesh Chaturvedi anim...@apache.org Unplug the nic when all the ips of public subnet is released Key: CLOUDSTACK-6183 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6183 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.3.0 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Priority: Critical Fix For: 4.3.0, 4.4.0 1. Add one public subnet 2. Aquire ips from the two subnets and configure the rules so that the nics get plugged in VR. 3. Release all the ips from the subnet Expected: 4. After all ips release the nic on the VR specific to this subnet get removed. Bug: The nic is not unplugged and it can't be reused for other subnets if we add. -- This message was sent by Atlassian JIRA (v6.2#6252)
