[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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:///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-tabpanel&focusedCommentId=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 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-tabpanel&focusedCommentId=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:///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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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=listAccounts&response=json&sessionkey=2%2Bf%2BWC0FhPn6j%2BiLp3mj2POhdsY%3D&listAll=true&page=1&pagesize=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=listAccounts&response=json&sessionkey=XkWSjL0e3Xe3ckgR5jW2CsSYOeA%3D&listAll=true&page=1&pagesize=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(ApplicationFilterCha
[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-tabpanel&focusedCommentId=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 > [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)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=14161524#comment-14161524 ] ASF subversion and git services commented on CLOUDSTACK-7674: - Commit 1a1190eb1dea8057c4ac5fef7811c5f37d162954 in cloudstack's branch refs/heads/4.3 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1a1190e ] CLOUDSTACK-7674 throw an exception when encountered > 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-7219) Cannot display Cluster Settings after 4.4 Upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161525#comment-14161525 ] Wei Zhou commented on CLOUDSTACK-7219: -- Branch: refs/heads/hotfix/4.4/CLOUDSTACK-7219 Commit: 0b31732bb18983db6cdd747a6c2f6056cf81a85e Parents: 63fbd16 Author: Harikrishna Patnala Authored: Fri Feb 7 16:44:11 2014 +0530 Committer: Wei Zhou Committed: Thu Oct 2 12:18:13 2014 +0200 > Cannot display Cluster Settings after 4.4 Upgrade > - > > Key: CLOUDSTACK-7219 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7219 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: 4.4.0 > Environment: CentOS 6, KVM Hypervisor >Reporter: Prieur Leary >Priority: Blocker > Fix For: 4.4.1 > > Attachments: cluster.png > > > After upgrading MS to 4.4, when you to go: > Home -> Infrastructure -> Clusters -> Cluster 1 - > Settings > It does not display the settings underneath the column heading just, "ERROR". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=14161537#comment-14161537 ] Carlos Reategui commented on CLOUDSTACK-7674: - Not sure that will fix my problem. My vlan table got updated properly by this code. The problem was the networks table. from my prior backup: INSERT INTO `vlan` VALUES (1,'5ebc3075-2946-4be4-9e7a-f32a86e7edfc','untagged','172.30.45.1','255.255.255.0','172.30.45.100-172.30.45.174','DirectAttached',1,204,200,NULL,NULL,NULL); after update: INSERT INTO `vlan` VALUES (1,'5ebc3075-2946-4be4-9e7a-f32a86e7edfc','vlan://untagged','172.30.45.1','255.255.255.0','172.30.45.100-172.30.45.174','DirectAttached',1,204,200,NULL,NULL,NULL); As you can see the vlan_id got updated properly. The problem for me was that the broadcast_uri for the guest network in the `networks` table stayed NULL. > 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)
