[jira] [Created] (CLOUDSTACK-7671) [RHEL7] management server failed to start once machine is rebooted
Damodar Reddy T created CLOUDSTACK-7671: --- Summary: [RHEL7] management server failed to start once machine is rebooted Key: CLOUDSTACK-7671 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7671 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Damodar Reddy T Assignee: Damodar Reddy T Repro stesp: Create a rhel 7 host Install MS Start MS Once MS is up and running . Reboot MS . Notice Cloudstack-management service status Bug: Notice MS fails to start even after calling service cloudstack-management restart it failed to start systemctl status cloudstack-management.service cloudstack-management.service - Citrix Cloud Plaltform Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; enabled) Active: failed (Result: exit-code) since Tue 2014-09-23 12:10:09 IST; 1min 28s ago Process: 4618 ExecStart=/usr/sbin/cloudstack-management start (code=exited, status=1/FAILURE) Sep 23 12:10:09 Rack1Pod1Host27 systemd[1]: Starting Citrix Cloud Plaltform... Sep 23 12:10:09 Rack1Pod1Host27 cloudstack-management[4618]: /usr/sbin/tomcat: line 50: /var/run/cloudstack-management.pid: Permission denied Sep 23 12:10:09 Rack1Pod1Host27 systemd[1]: cloudstack-management.service: control process exited, code=exited status=1 Sep 23 12:10:09 Rack1Pod1Host27 systemd[1]: Failed to start Citrix Cloud Plaltform. Sep 23 12:10:09 Rack1Pod1Host27 systemd[1]: Unit cloudstack-management.service entered failed state. [root@Rack1Pod1Host27 run]# service cloudstack-management status Redirecting to /bin/systemctl status cloudstack-management.service cloudstack-management.service - Citrix Cloud Plaltform Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; enabled) Active: failed (Result: exit-code) since Tue 2014-09-23 12:14:05 IST; 8s ago Process: 4691 ExecStart=/usr/sbin/cloudstack-management start (code=exited, status=1/FAILURE) Sep 23 12:14:05 Rack1Pod1Host27 cloudstack-management[4691]: /usr/sbin/tomcat: line 50: /var/run/cloudstack-management.pid: Permission denied Sep 23 12:14:05 Rack1Pod1Host27 systemd[1]: cloudstack-management.service: control process exited, code=exited status=1 Sep 23 12:14:05 Rack1Pod1Host27 systemd[1]: Failed to start Citrix Cloud Plaltform. Sep 23 12:14:05 Rack1Pod1Host27 systemd[1]: Unit cloudstack-management.service entered failed state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7646) test_nuage_vsp.py - Fix indentation issues and list out of index, mark test case as invalid, should be moved to BVT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-7646: --- Status: Reviewable (was: In Progress) test_nuage_vsp.py - Fix indentation issues and list out of index, mark test case as invalid, should be moved to BVT --- Key: CLOUDSTACK-7646 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7646 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Environment: Observed on KVM Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 This test has many indentation issues and list index issues. Also even after fixing the issues the test case does not pass which indicates it has not run before adding to regression test cases. It should be marked as Invalid. After author fixes the remaining issues, this test suite should be moved to Smoke (BVT) as it has only one test case which is clearly a BVT. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7649) test_lb_secondary_ip.py - test case failing during SSH when VM is detroyed and recovered
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-7649: --- Status: Reviewable (was: In Progress) test_lb_secondary_ip.py - test case failing during SSH when VM is detroyed and recovered Key: CLOUDSTACK-7649 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7649 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Environment: Observed on KVM Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The test case test_20_destroy_recover_vm fails while SSH connection after destroying and recovering VM. It fails because the secondary IP configuration is lost when VM is destroyed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7644) test_persistent_networks.py - SSH failure in case of LB rules due to port mismatch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-7644: --- Status: Reviewable (was: In Progress) test_persistent_networks.py - SSH failure in case of LB rules due to port mismatch -- Key: CLOUDSTACK-7644 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7644 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Environment: Observed in KVM Regression runs Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 Test case which try SSH to VM after creating LB rule fail during SSH. The SSH method tries to connect via SSH to default port 22, but LB rule is created for public port . Hence in this case, port number should be explicitly passed while trying SSH. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7672) Virtual routers HA do not serve correctly the root password service for starting VMs
JF Vincent created CLOUDSTACK-7672: -- Summary: Virtual routers HA do not serve correctly the root password service for starting VMs Key: CLOUDSTACK-7672 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7672 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.3.0 Environment: VMware Reporter: JF Vincent When the HA virtual router is selected, Both DHCP servers are active and thus when the VM is trying to get the root password server, the request will fail each time the first DHCP server to respond is the passive one. Very annoying. Regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7673) [Automation] integration.smoke.test_ssvm.TestSSVMs tests only comparing first gateway found
Alex Brett created CLOUDSTACK-7673: -- Summary: [Automation] integration.smoke.test_ssvm.TestSSVMs tests only comparing first gateway found Key: CLOUDSTACK-7673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7673 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Alex Brett Assignee: Alex Brett Fix For: 4.5.0 When running with an EIP zone, the API listVlanRanges gives two gateways back. integration.smoke.test_ssvm.TestSSVMs assumes however that there is only one, and so just picks the first. Unfortunately in EIP it seems the 'correct' one for the SSVM is the second, so the test fails. The test should therefore be modified to check if the SSVM gateway matches one of the IPs from listVlanRanges. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7673) [Automation] integration.smoke.test_ssvm.TestSSVMs tests only comparing first gateway found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14160407#comment-14160407 ] Alex Brett commented on CLOUDSTACK-7673: Review requested posted at https://reviews.apache.org/r/26364/ [Automation] integration.smoke.test_ssvm.TestSSVMs tests only comparing first gateway found --- Key: CLOUDSTACK-7673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7673 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Alex Brett Assignee: Alex Brett Fix For: 4.5.0 When running with an EIP zone, the API listVlanRanges gives two gateways back. integration.smoke.test_ssvm.TestSSVMs assumes however that there is only one, and so just picks the first. Unfortunately in EIP it seems the 'correct' one for the SSVM is the second, so the test fails. The test should therefore be modified to check if the SSVM gateway matches one of the IPs from listVlanRanges. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7674) Upgrade to 4.3.1 did not update broadcast_uri in networks table for basic zone type
Carlos Reategui created CLOUDSTACK-7674: --- Summary: Upgrade to 4.3.1 did not update broadcast_uri in networks table for basic zone type Key: CLOUDSTACK-7674 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7674 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Upgrade Affects Versions: 4.3.1 Environment: CS Manager on Ubuntu 12.04 from standard repo Hosts: XenServer 6.0.2 Zone: Basic Network Offering: DefaultSharedNetworkOffering Reporter: Carlos Reategui In previous versions, the broadcast_uri in the Networks table was NULL for Guest network in a Basic Zone with a network offering of DefaultSharedNetworkOffering. From 4.3.1 (maybe 4.3.0 too but not sure) it can not be NULL and must be set to vlan://untagged. The upgrade scripts do not do this and therefore one is unable to create new instances. I don't know if this affect other hypervisors besides XenServer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7674) Upgrade to 4.3.1 did not update broadcast_uri in networks table for basic zone type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amogh Vasekar updated CLOUDSTACK-7674: -- Priority: Critical (was: Major) Upgrade to 4.3.1 did not update broadcast_uri in networks table for basic zone type --- Key: CLOUDSTACK-7674 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7674 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Upgrade Affects Versions: 4.3.1 Environment: CS Manager on Ubuntu 12.04 from standard repo Hosts: XenServer 6.0.2 Zone: Basic Network Offering: DefaultSharedNetworkOffering Reporter: Carlos Reategui Priority: Critical In previous versions, the broadcast_uri in the Networks table was NULL for Guest network in a Basic Zone with a network offering of DefaultSharedNetworkOffering. From 4.3.1 (maybe 4.3.0 too but not sure) it can not be NULL and must be set to vlan://untagged. The upgrade scripts do not do this and therefore one is unable to create new instances. I don't know if this affect other hypervisors besides XenServer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6478) Failed to download Template when having 3 SSVM's in one zone on Vmware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14161082#comment-14161082 ] ASF subversion and git services commented on CLOUDSTACK-6478: - Commit 9e7fbae52fcbc2a99120d08158c6c99bdbd75b2c in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9e7fbae ] Revert CLOUDSTACK-7533: Wrong download URL is generated when using multiple SSVMs in a zone. The public ip of the url would sometime point to the wrong ssvm when the url was created on another one. This reverts commit f3b5a6ebc70d5bfb2c77b6aa359d7eb79b4507e5. Reverting since a better fix is available with CLOUDSTACK-6478 Failed to download Template when having 3 SSVM's in one zone on Vmware -- Key: CLOUDSTACK-6478 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6478 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.4.0 For VMWare, failed to download Template when having 3 SSVM's in one zone When trying to download template, a dialog with download URI like following displayed https://one ssvm ip/userdata/06b2ae45-c681-4952-802b-2f64b5832720.ova When trying to click on the link above, following error message is displayed in the browser. 404 Not Found When replaced IP address of download URL with another ssvm ip, then we could download the template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7533) [Vmware] Wrong download URL generated when using multiple SSVMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14161081#comment-14161081 ] ASF subversion and git services commented on CLOUDSTACK-7533: - Commit 9e7fbae52fcbc2a99120d08158c6c99bdbd75b2c in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9e7fbae ] Revert CLOUDSTACK-7533: Wrong download URL is generated when using multiple SSVMs in a zone. The public ip of the url would sometime point to the wrong ssvm when the url was created on another one. This reverts commit f3b5a6ebc70d5bfb2c77b6aa359d7eb79b4507e5. Reverting since a better fix is available with CLOUDSTACK-6478 [Vmware] Wrong download URL generated when using multiple SSVMs --- Key: CLOUDSTACK-7533 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7533 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.5.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7675) Public IP accounting wrong result in create VM due to Maximum number of public IP addresses”
Sheng Yang created CLOUDSTACK-7675: -- Summary: Public IP accounting wrong result in create VM due to Maximum number of public IP addresses” Key: CLOUDSTACK-7675 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7675 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Reporter: Sheng Yang Assignee: Anthony Xu Priority: Critical Fix For: 4.5.0 It's a newly found issue with statistic code. Reproduce steps: 1. Create a new account, with public ip limit set to 1. 2. Login using new account, create a new isolated network(so public ip would be used as source nat IP). 3. Login as admin, create an shared network. Make sure it's visible to newly created account. 4. Login using new account, create a new VM with the shared network, it would fail. Complaining maximum public IP reached. 5. Create a new VM with both isolated and shared networks, it would fail. Complaining maximum public IP reached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7675) Public IP accounting wrong result in create VM due to Maximum number of public IP addresses”
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-7675. Resolution: Fixed Fixed by: commit 3201251256817a44b4046c77c170fa82267e3fc3 Author: Anthony Xu anthony...@citrix.com Date: Thu Oct 2 16:02:33 2014 -0700 ccp should not check public ip resource when deploy a vm on shared network Public IP accounting wrong result in create VM due to Maximum number of public IP addresses” - Key: CLOUDSTACK-7675 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7675 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Reporter: Sheng Yang Assignee: Anthony Xu Priority: Critical Fix For: 4.5.0 It's a newly found issue with statistic code. Reproduce steps: 1. Create a new account, with public ip limit set to 1. 2. Login using new account, create a new isolated network(so public ip would be used as source nat IP). 3. Login as admin, create an shared network. Make sure it's visible to newly created account. 4. Login using new account, create a new VM with the shared network, it would fail. Complaining maximum public IP reached. 5. Create a new VM with both isolated and shared networks, it would fail. Complaining maximum public IP reached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6478) Failed to download Template when having 3 SSVM's in one zone on Vmware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14161158#comment-14161158 ] ASF subversion and git services commented on CLOUDSTACK-6478: - Commit aed36c2776500976b7e97ad0afcf132044d96b1c in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aed36c2 ] CLOUDSTACK-6478:Fix a typo in RemoteHostEndPoint.setId(). Failed to download Template when having 3 SSVM's in one zone on Vmware -- Key: CLOUDSTACK-6478 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6478 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.4.0 For VMWare, failed to download Template when having 3 SSVM's in one zone When trying to download template, a dialog with download URI like following displayed https://one ssvm ip/userdata/06b2ae45-c681-4952-802b-2f64b5832720.ova When trying to click on the link above, following error message is displayed in the browser. 404 Not Found When replaced IP address of download URL with another ssvm ip, then we could download the template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6278) Baremetal Advanced Networking support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14161169#comment-14161169 ] ASF subversion and git services commented on CLOUDSTACK-6278: - Commit 01dada100a34f42520446a64e02bd8eb2cf4e7fe in cloudstack's branch refs/heads/master from [~frank.zhang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=01dada1 ] CLOUDSTACK-6278 Baremetal Advanced Networking support Baremetal Advanced Networking support - Key: CLOUDSTACK-6278 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6278 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Baremetal Affects Versions: 4.5.0 Reporter: frank zhang Assignee: frank zhang Fix For: 4.5.0 functional spec link: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Baremetal+Advanced+Networking+Support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6278) Baremetal Advanced Networking support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14161175#comment-14161175 ] ASF subversion and git services commented on CLOUDSTACK-6278: - Commit 6dd3a91864711ba4a37a3216b6cb8cd924befe07 in cloudstack's branch refs/heads/master from [~frank.zhang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6dd3a91 ] CLOUDSTACK-6278 Baremetal Advanced Networking support fix baremetal-vr.py license header Baremetal Advanced Networking support - Key: CLOUDSTACK-6278 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6278 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Baremetal Affects Versions: 4.5.0 Reporter: frank zhang Assignee: frank zhang Fix For: 4.5.0 functional spec link: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Baremetal+Advanced+Networking+Support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7523) java.lang.NullPointerException when listing accounts.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] frank zhang resolved CLOUDSTACK-7523. - Resolution: Fixed java.lang.NullPointerException when listing accounts. -- Key: CLOUDSTACK-7523 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7523 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: Build from master Reporter: Sangeetha Hariharan Assignee: frank zhang Priority: Critical Fix For: 4.5.0 Deploy a fresh Management server. After this try to list Accounts , by going to Accounts tab in UI. There is no entries returned and the UI keeps spinning. listAccounts() fail with return code - 530 . 2014-09-09 12:38:59,932 INFO [a.c.c.a.ApiServer] (catalina-exec-18:ctx-0c561c21 ctx-dcbc1d59) (userId=2 accountId=2 sessionId=600DA8E1BD8DC8B8DF75DD5B5FC9E7E9) 10.215.3.17 -- GET command=listAccountsresponse=jsonsessionkey=2%2Bf%2BWC0FhPn6j%2BiLp3mj2POhdsY%3DlistAll=truepage=1pagesize=20_=1410305103203 530 null Following exception seen in management server logs: 2014-09-09 08:39:22,417 DEBUG [c.c.a.ApiServlet] (catalina-exec-7:ctx-d2a3ffdc) ===START=== 10.216.50.29 -- GET command=listAccountsresponse=jsonsessionkey=XkWSjL0e3Xe3ckgR5jW2CsSYOeA%3DlistAll=truepage=1pagesize=20_=1410290672605 2014-09-09 08:39:22,832 ERROR [c.c.a.ApiServer] (catalina-exec-7:ctx-d2a3ffdc ctx-9db713ee) unhandled exception executing api command: [Ljava.lang.String;@1a1bdce4 java.lang.NullPointerException at com.cloud.api.query.dao.AccountJoinDaoImpl.setResourceLimits(AccountJoinDaoImpl.java:144) at com.cloud.api.query.dao.AccountJoinDaoImpl.newAccountResponse(AccountJoinDaoImpl.java:79) 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:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy111.newAccountResponse(Unknown Source) at com.cloud.api.ApiDBUtils.newAccountResponse(ApiDBUtils.java:1788) at com.cloud.api.query.ViewResponseHelper.createAccountResponse(ViewResponseHelper.java:353) at com.cloud.api.query.QueryManagerImpl.searchForAccounts(QueryManagerImpl.java:1835) at org.apache.cloudstack.api.command.user.account.ListAccountsCmd.execute(ListAccountsCmd.java:93) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:273) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:117) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:114) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:76) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at
[jira] [Created] (CLOUDSTACK-7676) Usage server failed to start if default java version is 1.6
Rayees Namathponnan created CLOUDSTACK-7676: --- Summary: Usage server failed to start if default java version is 1.6 Key: CLOUDSTACK-7676 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7676 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.5.0 Reporter: Rayees Namathponnan Priority: Critical Fix For: 4.5.0 Steps to reproduce Install usage server on RHEL 6.3 machine check default. java version start usage server Result If default java versionis java 1.6, then management serer will fails to start Solution While starting usage server, we need to check java 1.7 exist or not, if exist then we need to start usage server with java 1.7 #The first existing directory is used for JAVA_HOME (if JAVA_HOME is not defined in $DEFAULT) if [[ ! -d $JAVA_HOME -d /usr/lib/jvm/jre-1.7.0 ]]; then export JAVA_HOME=/usr/lib/jvm/jre-1.7.0 PATH=$JAVA_HOME/bin:$PATH fi # use $JAVA_HOME if defined if [ -n $JAVA_HOME ] ; then return fi -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6282) [Automation]: Adding new Testcases
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14161460#comment-14161460 ] ASF subversion and git services commented on CLOUDSTACK-6282: - Commit d7dea70e89e45b0864bfbcaab3b58f896a6c75c1 in cloudstack's branch refs/heads/master from [~vinayv] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d7dea70 ] CLOUDSTACK-6282-Added hyper-v hypervisor checks for automated tests Signed-off-by: Santhosh Edukulla santhosh.eduku...@gmail.com [Automation]: Adding new Testcases -- Key: CLOUDSTACK-6282 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6282 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Vinay Vegesna Assignee: Santhosh Kumar Edukulla [Automation]: Adding below new Test cases for test_escalations.py test_01_list_volumes_pagination test_02_list_volume_byid test_03_data_volume_resize test_04_custom_volume test_05_volume_snapshot test_06_volume_snapshot_policy test_07_volume_snapshots_pagination test_08_volume_extract test_09_volume_upload -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7660) Enhance system vm template to support baremetal
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala updated CLOUDSTACK-7660: Status: Reviewable (was: In Progress) Enhance system vm template to support baremetal --- Key: CLOUDSTACK-7660 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7660 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.5.0 Reporter: frank zhang Assignee: Harikrishna Patnala Fix For: 4.5.0 Two things need doing: 1. pip install flask when building template 2. merge 7 disk partitions to single one -- This message was sent by Atlassian JIRA (v6.3.4#6332)
