[jira] [Created] (CLOUDSTACK-7747) VM Snapshot - Support only for vm revert cases that will not result in VM state change
Anshul Gangwar created CLOUDSTACK-7747: -- Summary: VM Snapshot - Support only for vm revert cases that will not result in VM state change Key: CLOUDSTACK-7747 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7747 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Currently we extend support for all the possible combinations .In cases were the Vm start changes from “Stopped” to “Running”, CS does not account for this VM’s capacity and VM start does not use our allocators. Following will be the only configuration we would have to support: 1.Revert a "Running" VM to a "Disk and Memory" Snapshot ( with and without "quiesce" option). 1.Revert a "Stopped" VM to a "Disk " Snapshot ( with and without "quiesce" option). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7741) UI login - 401 unable to verify user credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14174870#comment-14174870 ] Axel Delahaye commented on CLOUDSTACK-7741: --- when logging, browser hang on jquery.js:7829 "xhr.send( ( s.hasContent && s.data ) || null );" > UI login - 401 unable to verify user credentials > > > Key: CLOUDSTACK-7741 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7741 > 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: Cloudstack CentOS installation - 2 management servers >Reporter: JF Vincent >Priority: Critical > > After a period of time (after the night, second occurence) , on one of our > two servers, we're no more able to login. Google Chrome or Mozilla will hang > after pressing the login button. > After restarting the management server, problem disappear for many hours. > Here is the only error log in the apiserver.log : > 2014-10-16 14:46:04,181 INFO [a.c.c.a.ApiServer] > (http-6443-exec-196:ctx-ad974072) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463564799 401 > unable to verify user credentials > 2014-10-16 14:46:17,951 INFO [a.c.c.a.ApiServer] > (http-6443-exec-198:ctx-d04a1fce) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463578569 401 > unable to verify user credentials > 2014-10-16 14:49:10,622 INFO [a.c.c.a.ApiServer] > (http-6443-exec-200:ctx-e0099661) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463751221 401 > unable to verify user credentials > 2014-10-16 14:51:10,335 INFO [a.c.c.a.ApiServer] > (http-6443-exec-204:ctx-a6f3bd15) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463870965 401 > unable to verify user credentials > 2014-10-16 14:51:16,164 INFO [a.c.c.a.ApiServer] > (http-6443-exec-203:ctx-624e7433) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463876790 401 > unable to verify user credentials > while this server has the problem, on the other servr with is the backup we > don't have the problem. > The problem occurs for LDAP and local accounts. > Regards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7741) UI login - 401 unable to verify user credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14174884#comment-14174884 ] Wei Zhou commented on CLOUDSTACK-7741: -- Is there any error in management-server.log ? you can change the log4j level from INFO to DEBUG, then you will get more logs . > UI login - 401 unable to verify user credentials > > > Key: CLOUDSTACK-7741 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7741 > 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: Cloudstack CentOS installation - 2 management servers >Reporter: JF Vincent >Priority: Critical > > After a period of time (after the night, second occurence) , on one of our > two servers, we're no more able to login. Google Chrome or Mozilla will hang > after pressing the login button. > After restarting the management server, problem disappear for many hours. > Here is the only error log in the apiserver.log : > 2014-10-16 14:46:04,181 INFO [a.c.c.a.ApiServer] > (http-6443-exec-196:ctx-ad974072) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463564799 401 > unable to verify user credentials > 2014-10-16 14:46:17,951 INFO [a.c.c.a.ApiServer] > (http-6443-exec-198:ctx-d04a1fce) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463578569 401 > unable to verify user credentials > 2014-10-16 14:49:10,622 INFO [a.c.c.a.ApiServer] > (http-6443-exec-200:ctx-e0099661) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463751221 401 > unable to verify user credentials > 2014-10-16 14:51:10,335 INFO [a.c.c.a.ApiServer] > (http-6443-exec-204:ctx-a6f3bd15) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463870965 401 > unable to verify user credentials > 2014-10-16 14:51:16,164 INFO [a.c.c.a.ApiServer] > (http-6443-exec-203:ctx-624e7433) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463876790 401 > unable to verify user credentials > while this server has the problem, on the other servr with is the backup we > don't have the problem. > The problem occurs for LDAP and local accounts. > Regards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7741) UI login - 401 unable to verify user credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14174886#comment-14174886 ] JF Vincent commented on CLOUDSTACK-7741: not just that in the catalina.out : Catalina.out : 2014-10-17 09:42:22,888 DEBUG [c.c.a.ApiServlet] (http-6443-exec-467:ctx-86fe168f) ===START=== 10.26.238.65 -- POST 2014-10-17 09:42:22,891 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-467:ctx-86fe168f) Attempting to log in user: jf in domain 1 2014-10-17 09:42:22,892 DEBUG [c.c.s.a.SHA256SaltedUserAuthenticator] (http-6443-exec-467:ctx-86fe168f) Retrieving user: jf 2014-10-17 09:42:22,900 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-467:ctx-86fe168f) User: jf in domain 1 has successfully logged in > UI login - 401 unable to verify user credentials > > > Key: CLOUDSTACK-7741 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7741 > 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: Cloudstack CentOS installation - 2 management servers >Reporter: JF Vincent >Priority: Critical > > After a period of time (after the night, second occurence) , on one of our > two servers, we're no more able to login. Google Chrome or Mozilla will hang > after pressing the login button. > After restarting the management server, problem disappear for many hours. > Here is the only error log in the apiserver.log : > 2014-10-16 14:46:04,181 INFO [a.c.c.a.ApiServer] > (http-6443-exec-196:ctx-ad974072) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463564799 401 > unable to verify user credentials > 2014-10-16 14:46:17,951 INFO [a.c.c.a.ApiServer] > (http-6443-exec-198:ctx-d04a1fce) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463578569 401 > unable to verify user credentials > 2014-10-16 14:49:10,622 INFO [a.c.c.a.ApiServer] > (http-6443-exec-200:ctx-e0099661) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463751221 401 > unable to verify user credentials > 2014-10-16 14:51:10,335 INFO [a.c.c.a.ApiServer] > (http-6443-exec-204:ctx-a6f3bd15) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463870965 401 > unable to verify user credentials > 2014-10-16 14:51:16,164 INFO [a.c.c.a.ApiServer] > (http-6443-exec-203:ctx-624e7433) 10.26.238.66 -- GET > command=listCapabilities&response=json&sessionkey=null&_=1413463876790 401 > unable to verify user credentials > while this server has the problem, on the other servr with is the backup we > don't have the problem. > The problem occurs for LDAP and local accounts. > Regards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7748) VM Deployment with new templates failing: Unable to start instance due to For input string: "Thu"
Harikrishna Patnala created CLOUDSTACK-7748:
---
Summary: VM Deployment with new templates failing: Unable to start
instance due to For input string: "Thu"
Key: CLOUDSTACK-7748
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7748
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server, Template
Affects Versions: 4.5.0
Reporter: Harikrishna Patnala
Assignee: Harikrishna Patnala
Fix For: 4.5.0
>From the management server log when router version is checked we can see it
>takes in Thu and in converting the string to int throws an exception.
{"com.cloud.agent.api.GetDomRVersionAnswer":{"templateVersion":"Cloudstack
Release Thu Oct 2 06:01:22 UTC
2014","scriptsVersion":"71aa301dbe5af3a821cce407252988a6\n","result":
{noformat}
2014-10-13 16:16:57,198 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-12:ctx-239d390a job-21/job-44) Unable to complete AsyncJobVO
{id:44, userId: 2, accountId: 2, instanceType: null, instanceId: null, cmd:
com.cloud.vm.VmWorkStart, cmdInfo:
rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAACAAIABHQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AApWbVBhc3N3b3JkdAAcck8wQUJYUUFEbk5oZG1Wa1gzQmhjM04zYjNKa3hw,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 90827021567974, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Mon Oct 13 16:16:26 UTC 2014}, job origin:21
com.cloud.exception.AgentUnavailableException: Resource [Host:2] is
unreachable: Host 2: Unable to start instance due to For input string: "Thu"
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1090)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4590)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4746)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:513)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:470)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.NumberFormatException: For input string: "Thu"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Long.parseLong(Long.java:441)
at java.lang.Long.parseLong(Long.java:483)
at com.cloud.maint.Version.compare(Version.java:36)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.checkRouterVersion(VirtualNetworkApplianceManagerImpl.java:4390)
at
com.cloud.network.router.VirtualNetworkApplian
[jira] [Commented] (CLOUDSTACK-7748) VM Deployment with new templates failing: Unable to start instance due to For input string: "Thu"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14174952#comment-14174952
]
Harikrishna Patnala commented on CLOUDSTACK-7748:
-
While building the system templates version number is overridden with empty
string in /tools/appliance/build.sh
> VM Deployment with new templates failing: Unable to start instance due to For
> input string: "Thu"
> -
>
> Key: CLOUDSTACK-7748
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7748
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Template
>Affects Versions: 4.5.0
>Reporter: Harikrishna Patnala
>Assignee: Harikrishna Patnala
> Fix For: 4.5.0
>
>
> From the management server log when router version is checked we can see it
> takes in Thu and in converting the string to int throws an exception.
> {"com.cloud.agent.api.GetDomRVersionAnswer":{"templateVersion":"Cloudstack
> Release Thu Oct 2 06:01:22 UTC
> 2014","scriptsVersion":"71aa301dbe5af3a821cce407252988a6\n","result":
> {noformat}
> 2014-10-13 16:16:57,198 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-12:ctx-239d390a job-21/job-44) Unable to complete
> AsyncJobVO {id:44, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.vm.VmWorkStart, cmdInfo:
> rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAACAAIABHQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AApWbVBhc3N3b3JkdAAcck8wQUJYUUFEbk5oZG1Wa1gzQmhjM04zYjNKa3hw,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 90827021567974, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Mon Oct 13 16:16:26 UTC 2014}, job origin:21
> com.cloud.exception.AgentUnavailableException: Resource [Host:2] is
> unreachable: Host 2: Unable to start instance due to For input string: "Thu"
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1090)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4590)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4746)
> at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:513)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:470)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NumberFormatException: For inpu
[jira] [Commented] (CLOUDSTACK-665) Health monitoring for HAProxy load balanced instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14175084#comment-14175084 ] Douglas Land commented on CLOUDSTACK-665: - We're using the built-in load-balancer in cloudstack and it's quite important to support healthchecks. I'm surprised this hasn't been bumped up in priority. I read the previous ticket and I think most people would be happy with any (http/tcp) checks versus no functionality, and not worrying about an extensive model to support other check types. If this isn't on the roadmap for 4.2 when is it planned for? We're needing to use an external haproxy instance right now and completely bypassing the built-in LB since it's kind of a deal-breaker to not support check/removal of backend systems. > Health monitoring for HAProxy load balanced instances > - > > Key: CLOUDSTACK-665 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-665 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Rajesh Battala > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7365) Upgrading without proper systemvm template corrupt cloudstack management server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-7365: -- Assignee: (was: Daan Hoogland) > Upgrading without proper systemvm template corrupt cloudstack management > server > --- > > Key: CLOUDSTACK-7365 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7365 > 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, 4.4.0, 4.4.1 >Reporter: Pierre-Luc Dion > Labels: upgrade > Attachments: 4.4.0to4.4.1_mgtlogissue.txt > > > Since 4.3.0, also affecting 4.4.0 and 4.4.1. When upgrading CloudStack > management server, it is required to have systemvm template properly named > prior to the upgrade. otherwise the management server will fail to restart > with after upgrading database schema. > The possible repair method is to revert packages to previously installed > CloudStack and restore the database which have been upgraded. > This is not a viable upgrade path since management servers packages could be > accidentally upgraded after a "yum upgrade" or "apt-get update". > Upgrading CloudStack management-server without previously uploading systemvm > template should not fail to start the management-server. if the systemvm > template is not in place, then the management-server cannot start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7365) Upgrading without proper systemvm template corrupt cloudstack management server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland reassigned CLOUDSTACK-7365: - Assignee: Daan Hoogland > Upgrading without proper systemvm template corrupt cloudstack management > server > --- > > Key: CLOUDSTACK-7365 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7365 > 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, 4.4.0, 4.4.1 >Reporter: Pierre-Luc Dion >Assignee: Daan Hoogland > Labels: upgrade > Attachments: 4.4.0to4.4.1_mgtlogissue.txt > > > Since 4.3.0, also affecting 4.4.0 and 4.4.1. When upgrading CloudStack > management server, it is required to have systemvm template properly named > prior to the upgrade. otherwise the management server will fail to restart > with after upgrading database schema. > The possible repair method is to revert packages to previously installed > CloudStack and restore the database which have been upgraded. > This is not a viable upgrade path since management servers packages could be > accidentally upgraded after a "yum upgrade" or "apt-get update". > Upgrading CloudStack management-server without previously uploading systemvm > template should not fail to start the management-server. if the systemvm > template is not in place, then the management-server cannot start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7365) Upgrading without proper systemvm template corrupt cloudstack management server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14175135#comment-14175135 ] Rohit Yadav commented on CLOUDSTACK-7365: - For XenServer, make sure you register/upload this template: http://cloudstack.apt-get.eu/systemvm/4.4/systemvm64template-4.4.0-6-xen.vhd.bz2 with name = "systemvm-xenserver-4.4" (watchout for spaces since the upgrade path uses this hardcoded value in a hashmap). And check that its checksum is 7a8a6c4f8478147f1c6aa0d20f5e62b9 (this is of the unextracted vhd.bz2 file). Note that you should upload all systemvm templates for all kinds of hypervisor clusters you have and not just for the default one (look the at the upgrade path code). I read the upgrade path again, so the issue is this upgrade path assumes that we're upgrading from 4.4.0 (not necessarily true), so it would fail in case 4.4.0 systemvm template is not found. Why it doing this? ([~dahn] should tell us since he added the upgrade systemvm method in 00c2696e7a1d1930a4088af6fc085b523b0b3589) >From code, looks like it is simply changing the systemvm template user to >SYSTEM user, updates template IDs and updates some configuration options. The solution to this I think should be that it searches only for 4.4.0, so if no systemvms are available we should at least update the configuration update statements, but don't throw exception since a user maybe upgrading from 4.3.1 etc. Also because if I'm upgrading to 4.4.1 or above I won't be interested in using/having 4.4.0 systemvm templates, at some point I would upgrade to those newer templates. Comments? > Upgrading without proper systemvm template corrupt cloudstack management > server > --- > > Key: CLOUDSTACK-7365 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7365 > 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, 4.4.0, 4.4.1 >Reporter: Pierre-Luc Dion > Labels: upgrade > Attachments: 4.4.0to4.4.1_mgtlogissue.txt > > > Since 4.3.0, also affecting 4.4.0 and 4.4.1. When upgrading CloudStack > management server, it is required to have systemvm template properly named > prior to the upgrade. otherwise the management server will fail to restart > with after upgrading database schema. > The possible repair method is to revert packages to previously installed > CloudStack and restore the database which have been upgraded. > This is not a viable upgrade path since management servers packages could be > accidentally upgraded after a "yum upgrade" or "apt-get update". > Upgrading CloudStack management-server without previously uploading systemvm > template should not fail to start the management-server. if the systemvm > template is not in place, then the management-server cannot start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7748) VM Deployment with new templates failing: Unable to start instance due to For input string: "Thu"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harikrishna Patnala updated CLOUDSTACK-7748:
Status: Reviewable (was: In Progress)
> VM Deployment with new templates failing: Unable to start instance due to For
> input string: "Thu"
> -
>
> Key: CLOUDSTACK-7748
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7748
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Template
>Affects Versions: 4.5.0
>Reporter: Harikrishna Patnala
>Assignee: Harikrishna Patnala
> Fix For: 4.5.0
>
>
> From the management server log when router version is checked we can see it
> takes in Thu and in converting the string to int throws an exception.
> {"com.cloud.agent.api.GetDomRVersionAnswer":{"templateVersion":"Cloudstack
> Release Thu Oct 2 06:01:22 UTC
> 2014","scriptsVersion":"71aa301dbe5af3a821cce407252988a6\n","result":
> {noformat}
> 2014-10-13 16:16:57,198 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-12:ctx-239d390a job-21/job-44) Unable to complete
> AsyncJobVO {id:44, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.vm.VmWorkStart, cmdInfo:
> rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAACAAIABHQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AApWbVBhc3N3b3JkdAAcck8wQUJYUUFEbk5oZG1Wa1gzQmhjM04zYjNKa3hw,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 90827021567974, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Mon Oct 13 16:16:26 UTC 2014}, job origin:21
> com.cloud.exception.AgentUnavailableException: Resource [Host:2] is
> unreachable: Host 2: Unable to start instance due to For input string: "Thu"
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1090)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4590)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4746)
> at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:513)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:470)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NumberFormatException: For input string: "Thu"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang
[jira] [Created] (CLOUDSTACK-7749) AsyncJob GC thread cannot purge queue items that have been blocking for too long if exception is thrown in expunging some unfinished or completed old jobs, this will
Min Chen created CLOUDSTACK-7749:
Summary: AsyncJob GC thread cannot purge queue items that have
been blocking for too long if exception is thrown in expunging some unfinished
or completed old jobs, this will make some future jobs stuck.
Key: CLOUDSTACK-7749
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7749
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
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
AsyncJobManager has a GC thread to clean up some unfinished job and complete
jobs that are too old. In this same thread, we are also forcefully cancel
blocking queue items if they've been staying there for too long. Currently if
there is an exception thrown in expunging one job, for example, like the one
below:
2014-10-14 17:57:26,347 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
(AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Expunging unfinished job AsyncJobVO
{id:18443, userId: 60, accountId: 69, instanceType: null, instanc eId: null,
cmd: com.cloud.vm.VmWorkStart, cmdInfo:
rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIACkoABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljb
HVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL
01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cABFADwCdXQAGVZpcnR1YWxNYWNoaW5lTWFuY
WdlckltcGwAAHBwcHBwcHBzcgARamF2YS51dGlsLkhhc2hNYXAFB9rBwxZg0QMAAkYACmxvYWRGYWN0b3JJAAl0aHJlc2hvbGR4cD9MdwgQAXQAClZtUGFzc3dvcmR0ABxyTzBBQlhRQURuTmhkbVZrWDNCaGMzTjNiM0preHA,
cmdVersi on: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 244536014864905, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Wed Aug 20 18:14:13 EDT 2014}
2014-10-14 17:57:26,350 DEBUG [c.c.u.d.T.Transaction]
(AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Rolling back the transaction: Time = 2
Name = AsyncJobMgr-Heartbeat-1; called by -TransactionLegacy.rollback:8
96-TransactionLegacy.removeUpTo:839-TransactionLegacy.close:663-TransactionContextInterceptor.invoke:35-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocat
ion.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy151.expunge:-1-AsyncJobManagerImpl$8.doInTransactionWithoutResult:802-TransactionCallbackNoReturn.doInTransaction:25-Transaction$2.doInTransaction:49
2014-10-14 17:57:26,368 ERROR [o.a.c.f.j.i.AsyncJobManagerImpl]
(AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Unexpected exception when trying to
execute queue item,
com.cloud.utils.exception.CloudRuntimeException: DB Exception on:
com.mysql.jdbc.JDBC4PreparedStatement@39fdfb52: DELETE FROM async_job WHERE
async_job.id= 18443
at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1144)
at sun.reflect.GeneratedMethodAccessor247.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:622)
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:33)
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.$Proxy151.expunge(Unknown Source)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$8.doInTransactionWithoutResult(AsyncJobManagerImpl.java:802)
at
com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25)
at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49)
at com.cloud.utils.db.Transaction.execute(Transaction.java:37)
at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl.expungeAsyncJob(AsyncJobManagerImpl.java:799)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJ
[jira] [Commented] (CLOUDSTACK-7749) AsyncJob GC thread cannot purge queue items that have been blocking for too long if exception is thrown in expunging some unfinished or completed old jobs, this wi
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14175302#comment-14175302
]
ASF subversion and git services commented on CLOUDSTACK-7749:
-
Commit 248e4fbdacb1372da94cbcf49ca23a14c8c9b514 in cloudstack's branch
refs/heads/master from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=248e4fb ]
CLOUDSTACK-7749: AsyncJob GC thread cannot purge queue items that have been
blocking for too long if exception is thrown in expunging some unfinished or
completed old jobs, this will make some future jobs stuck.
> AsyncJob GC thread cannot purge queue items that have been blocking for too
> long if exception is thrown in expunging some unfinished or completed old
> jobs, this will make some future jobs stuck.
> --
>
> Key: CLOUDSTACK-7749
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7749
> 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
>Reporter: Min Chen
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.5.0
>
>
> AsyncJobManager has a GC thread to clean up some unfinished job and complete
> jobs that are too old. In this same thread, we are also forcefully cancel
> blocking queue items if they've been staying there for too long. Currently if
> there is an exception thrown in expunging one job, for example, like the one
> below:
> 2014-10-14 17:57:26,347 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Expunging unfinished job AsyncJobVO
> {id:18443, userId: 60, accountId: 69, instanceType: null, instanc eId: null,
> cmd: com.cloud.vm.VmWorkStart, cmdInfo:
> rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIACkoABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljb
>
> HVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL
>
> 01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cABFADwCdXQAGVZpcnR1YWxNYWNoaW5lTWFuY
>
> WdlckltcGwAAHBwcHBwcHBzcgARamF2YS51dGlsLkhhc2hNYXAFB9rBwxZg0QMAAkYACmxvYWRGYWN0b3JJAAl0aHJlc2hvbGR4cD9MdwgQAXQAClZtUGFzc3dvcmR0ABxyTzBBQlhRQURuTmhkbVZrWDNCaGMzTjNiM0preHA,
> cmdVersi on: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
> result: null, initMsid: 244536014864905, completeMsid: null, lastUpdated:
> null, lastPolled: null, created: Wed Aug 20 18:14:13 EDT 2014}
> 2014-10-14 17:57:26,350 DEBUG [c.c.u.d.T.Transaction]
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Rolling back the transaction: Time = 2
> Name = AsyncJobMgr-Heartbeat-1; called by -TransactionLegacy.rollback:8
> 96-TransactionLegacy.removeUpTo:839-TransactionLegacy.close:663-TransactionContextInterceptor.invoke:35-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocat
> ion.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy151.expunge:-1-AsyncJobManagerImpl$8.doInTransactionWithoutResult:802-TransactionCallbackNoReturn.doInTransaction:25-Transaction$2.doInTransaction:49
> 2014-10-14 17:57:26,368 ERROR [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Unexpected exception when trying to
> execute queue item,
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on:
> com.mysql.jdbc.JDBC4PreparedStatement@39fdfb52: DELETE FROM async_job WHERE
> async_job.id= 18443
> at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1144)
> at sun.reflect.GeneratedMethodAccessor247.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:622)
> 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:33)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at
> org.springframework.aop.interceptor.Ex
[jira] [Updated] (CLOUDSTACK-7746) Baremetal related script erros seen on router console
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan updated CLOUDSTACK-7746: Assignee: (was: Rayees Namathponnan) > Baremetal related script erros seen on router console > - > > Key: CLOUDSTACK-7746 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7746 > 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 >Priority: Critical > Fix For: 4.5.0 > > Attachments: router.png > > > Baremetal related script erros seen on router console. > Advanced zone set up with 3 xenserver hosts in a cluster. > When logging into the console view of router , following script errors are > seen: > /opt/cloud/bin/baremetal-vr.py:159: SyntaxWarning : name 'server' is assigned > to before glocal declaration. .. > Attached is the screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7746) Baremetal related script erros seen on router console
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan reassigned CLOUDSTACK-7746: --- Assignee: Rayees Namathponnan > Baremetal related script erros seen on router console > - > > Key: CLOUDSTACK-7746 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7746 > 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: Rayees Namathponnan >Priority: Critical > Fix For: 4.5.0 > > Attachments: router.png > > > Baremetal related script erros seen on router console. > Advanced zone set up with 3 xenserver hosts in a cluster. > When logging into the console view of router , following script errors are > seen: > /opt/cloud/bin/baremetal-vr.py:159: SyntaxWarning : name 'server' is assigned > to before glocal declaration. .. > Attached is the screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7749) AsyncJob GC thread cannot purge queue items that have been blocking for too long if exception is thrown in expunging some unfinished or completed old jobs, this wi
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14175321#comment-14175321
]
ASF subversion and git services commented on CLOUDSTACK-7749:
-
Commit dbf12d58e713ee5d3a120999cebf5a87d728b209 in cloudstack's branch
refs/heads/4.5 from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dbf12d5 ]
CLOUDSTACK-7749: AsyncJob GC thread cannot purge queue items that have been
blocking for too long if exception is thrown in expunging some unfinished or
completed old jobs, this will make some future jobs stuck.
> AsyncJob GC thread cannot purge queue items that have been blocking for too
> long if exception is thrown in expunging some unfinished or completed old
> jobs, this will make some future jobs stuck.
> --
>
> Key: CLOUDSTACK-7749
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7749
> 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
>Reporter: Min Chen
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.5.0
>
>
> AsyncJobManager has a GC thread to clean up some unfinished job and complete
> jobs that are too old. In this same thread, we are also forcefully cancel
> blocking queue items if they've been staying there for too long. Currently if
> there is an exception thrown in expunging one job, for example, like the one
> below:
> 2014-10-14 17:57:26,347 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Expunging unfinished job AsyncJobVO
> {id:18443, userId: 60, accountId: 69, instanceType: null, instanc eId: null,
> cmd: com.cloud.vm.VmWorkStart, cmdInfo:
> rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIACkoABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljb
>
> HVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL
>
> 01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cABFADwCdXQAGVZpcnR1YWxNYWNoaW5lTWFuY
>
> WdlckltcGwAAHBwcHBwcHBzcgARamF2YS51dGlsLkhhc2hNYXAFB9rBwxZg0QMAAkYACmxvYWRGYWN0b3JJAAl0aHJlc2hvbGR4cD9MdwgQAXQAClZtUGFzc3dvcmR0ABxyTzBBQlhRQURuTmhkbVZrWDNCaGMzTjNiM0preHA,
> cmdVersi on: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
> result: null, initMsid: 244536014864905, completeMsid: null, lastUpdated:
> null, lastPolled: null, created: Wed Aug 20 18:14:13 EDT 2014}
> 2014-10-14 17:57:26,350 DEBUG [c.c.u.d.T.Transaction]
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Rolling back the transaction: Time = 2
> Name = AsyncJobMgr-Heartbeat-1; called by -TransactionLegacy.rollback:8
> 96-TransactionLegacy.removeUpTo:839-TransactionLegacy.close:663-TransactionContextInterceptor.invoke:35-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocat
> ion.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy151.expunge:-1-AsyncJobManagerImpl$8.doInTransactionWithoutResult:802-TransactionCallbackNoReturn.doInTransaction:25-Transaction$2.doInTransaction:49
> 2014-10-14 17:57:26,368 ERROR [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Unexpected exception when trying to
> execute queue item,
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on:
> com.mysql.jdbc.JDBC4PreparedStatement@39fdfb52: DELETE FROM async_job WHERE
> async_job.id= 18443
> at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1144)
> at sun.reflect.GeneratedMethodAccessor247.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:622)
> 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:33)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at
> org.springframework.aop.interceptor.Expos
[jira] [Resolved] (CLOUDSTACK-7749) AsyncJob GC thread cannot purge queue items that have been blocking for too long if exception is thrown in expunging some unfinished or completed old jobs, this wil
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-7749.
--
Resolution: Fixed
> AsyncJob GC thread cannot purge queue items that have been blocking for too
> long if exception is thrown in expunging some unfinished or completed old
> jobs, this will make some future jobs stuck.
> --
>
> Key: CLOUDSTACK-7749
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7749
> 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
>Reporter: Min Chen
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.5.0
>
>
> AsyncJobManager has a GC thread to clean up some unfinished job and complete
> jobs that are too old. In this same thread, we are also forcefully cancel
> blocking queue items if they've been staying there for too long. Currently if
> there is an exception thrown in expunging one job, for example, like the one
> below:
> 2014-10-14 17:57:26,347 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Expunging unfinished job AsyncJobVO
> {id:18443, userId: 60, accountId: 69, instanceType: null, instanc eId: null,
> cmd: com.cloud.vm.VmWorkStart, cmdInfo:
> rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIACkoABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljb
>
> HVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL
>
> 01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cABFADwCdXQAGVZpcnR1YWxNYWNoaW5lTWFuY
>
> WdlckltcGwAAHBwcHBwcHBzcgARamF2YS51dGlsLkhhc2hNYXAFB9rBwxZg0QMAAkYACmxvYWRGYWN0b3JJAAl0aHJlc2hvbGR4cD9MdwgQAXQAClZtUGFzc3dvcmR0ABxyTzBBQlhRQURuTmhkbVZrWDNCaGMzTjNiM0preHA,
> cmdVersi on: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
> result: null, initMsid: 244536014864905, completeMsid: null, lastUpdated:
> null, lastPolled: null, created: Wed Aug 20 18:14:13 EDT 2014}
> 2014-10-14 17:57:26,350 DEBUG [c.c.u.d.T.Transaction]
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Rolling back the transaction: Time = 2
> Name = AsyncJobMgr-Heartbeat-1; called by -TransactionLegacy.rollback:8
> 96-TransactionLegacy.removeUpTo:839-TransactionLegacy.close:663-TransactionContextInterceptor.invoke:35-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocat
> ion.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy151.expunge:-1-AsyncJobManagerImpl$8.doInTransactionWithoutResult:802-TransactionCallbackNoReturn.doInTransaction:25-Transaction$2.doInTransaction:49
> 2014-10-14 17:57:26,368 ERROR [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Unexpected exception when trying to
> execute queue item,
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on:
> com.mysql.jdbc.JDBC4PreparedStatement@39fdfb52: DELETE FROM async_job WHERE
> async_job.id= 18443
> at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1144)
> at sun.reflect.GeneratedMethodAccessor247.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:622)
> 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:33)
> 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.$Proxy151.expunge(Unknown Source)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$8.doInTransactionWithoutResult(AsyncJobManagerImpl.java:802)
> at
> co
[jira] [Updated] (CLOUDSTACK-7430) [UI] no option to remove /delete host from cluster from UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-7430: - Attachment: 2014-10-17-jessica.PNG > [UI] no option to remove /delete host from cluster from UI > -- > > Key: CLOUDSTACK-7430 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7430 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang > Fix For: 4.5.0 > > Attachments: 2014-10-17-jessica.PNG, delete-host.png > > > Repro steps: > 1. Create a Zone > 2. Put host to maintenance > 3. when host is in maintenance try to remove/delete host from cluster via Ui > Bug: > No option to delete host > attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7430) [UI] no option to remove /delete host from cluster from UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-7430. -- Resolution: Fixed shweta, I'm unable to reproduce this bug. Delete Host option does show in my environment(as my attached screenshot). If you are able to reproduce this bug in your environment, please provide your database dump (against 4.5 branch). thank you. Jessica > [UI] no option to remove /delete host from cluster from UI > -- > > Key: CLOUDSTACK-7430 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7430 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang > Fix For: 4.5.0 > > Attachments: 2014-10-17-jessica.PNG, delete-host.png > > > Repro steps: > 1. Create a Zone > 2. Put host to maintenance > 3. when host is in maintenance try to remove/delete host from cluster via Ui > Bug: > No option to delete host > attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5576) RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-5576: - Attachment: 2014-10-17-jessica2.jpg 2014-10-17-jessica1.jpg > RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN" > - > > Key: CLOUDSTACK-5576 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5576 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Chandan Purushothama >Assignee: Jessica Wang >Priority: Minor > Fix For: 4.4.0 > > Attachments: 2014-10-17-jessica1.jpg, 2014-10-17-jessica2.jpg, > UICapture38.png > > > The corresponding UI Screenshot has been attached to the bug report. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5576) RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-5576: - Fix Version/s: (was: 4.4.0) 4.5.0 > RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN" > - > > Key: CLOUDSTACK-5576 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5576 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Chandan Purushothama >Assignee: Jessica Wang >Priority: Minor > Fix For: 4.5.0 > > Attachments: 2014-10-17-jessica1.jpg, 2014-10-17-jessica2.jpg, > UICapture38.png > > > The corresponding UI Screenshot has been attached to the bug report. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5576) RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14175604#comment-14175604 ] ASF subversion and git services commented on CLOUDSTACK-5576: - Commit e796d418b4ff7d3644bcc962b796d929b3d7baf7 in cloudstack's branch refs/heads/4.5 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e796d41 ] CLOUDSTACK-5576: UI > IP Address > EnableVPN, DisableVPN: change label. > RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN" > - > > Key: CLOUDSTACK-5576 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5576 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Chandan Purushothama >Assignee: Jessica Wang >Priority: Minor > Fix For: 4.5.0 > > Attachments: 2014-10-17-jessica1.jpg, 2014-10-17-jessica2.jpg, > UICapture38.png > > > The corresponding UI Screenshot has been attached to the bug report. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5576) RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14175607#comment-14175607 ] ASF subversion and git services commented on CLOUDSTACK-5576: - Commit 3db112f75c3e2391bce896c868095f3444e43451 in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3db112f ] CLOUDSTACK-5576: UI > IP Address > EnableVPN, DisableVPN: change label. > RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN" > - > > Key: CLOUDSTACK-5576 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5576 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Chandan Purushothama >Assignee: Jessica Wang >Priority: Minor > Fix For: 4.5.0 > > Attachments: 2014-10-17-jessica1.jpg, 2014-10-17-jessica2.jpg, > UICapture38.png > > > The corresponding UI Screenshot has been attached to the bug report. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-5576) RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-5576. -- Resolution: Fixed > RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN" > - > > Key: CLOUDSTACK-5576 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5576 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Chandan Purushothama >Assignee: Jessica Wang >Priority: Minor > Fix For: 4.5.0 > > Attachments: 2014-10-17-jessica1.jpg, 2014-10-17-jessica2.jpg, > UICapture38.png > > > The corresponding UI Screenshot has been attached to the bug report. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5576) RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-5576: - Labels: DEVREV (was: ) QA notes: - Enable VPN option should look like my attached screenshot. > RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN" > - > > Key: CLOUDSTACK-5576 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5576 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Chandan Purushothama >Assignee: Jessica Wang >Priority: Minor > Labels: DEVREV > Fix For: 4.5.0 > > Attachments: 2014-10-17-jessica1.jpg, 2014-10-17-jessica2.jpg, > UICapture38.png > > > The corresponding UI Screenshot has been attached to the bug report. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-5762) [dynamic compute offerings]UI change required for select compute offerinngs in add instance wizard
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-5762: Assignee: Brian Federle (was: Jessica Wang) Brian, This is a CSS issue. So, foward it to you. thanks. Jessica > [dynamic compute offerings]UI change required for select compute offerinngs > in add instance wizard > --- > > Key: CLOUDSTACK-5762 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5762 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: prashant kumar mishra >Assignee: Brian Federle >Priority: Trivial > Fix For: 4.4.0 > > Attachments: screenshot-1.jpg > > > "required" is overlapping on memory and cpu if dynamic compute offering > selected in deploy vm wizard .please check screenshot > Steps to repro > === > 1-preapare a CS 4.3 setup > 2-check select compute offering page in deploy vm wizard. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-4201) listServiceOfferings API needs to be able to take virtualmachineid of SystemVM and return service offerings available for the vm to change service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-4201: Fix Version/s: (was: 4.5.0) 4.6.0 > listServiceOfferings API needs to be able to take virtualmachineid of > SystemVM and return service offerings available for the vm to change service > offering > --- > > Key: CLOUDSTACK-4201 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4201 > 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 > Environment: listServiceOfferings API needs to be able to take > virtualmachineid of SystemVM and returns service offerings available for the > vm to change service offering. If vm is running only scale up service > offering should be presented. If vm is stopped all service offering should be > shown >Reporter: Nitin Mehta >Assignee: Nitin Mehta > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-4201) listServiceOfferings API needs to be able to take virtualmachineid of SystemVM and return service offerings available for the vm to change service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840417#comment-13840417 ] Nitin Mehta edited comment on CLOUDSTACK-4201 at 10/17/14 10:39 PM: This is a good to have but not a critical. Downgrading the priority to Major and moving it to 4.6 was (Author: nitinme): This is a good to have but not a critical. Downgrading the priority to Major and moving it to future > listServiceOfferings API needs to be able to take virtualmachineid of > SystemVM and return service offerings available for the vm to change service > offering > --- > > Key: CLOUDSTACK-4201 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4201 > 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 > Environment: listServiceOfferings API needs to be able to take > virtualmachineid of SystemVM and returns service offerings available for the > vm to change service offering. If vm is running only scale up service > offering should be presented. If vm is stopped all service offering should be > shown >Reporter: Nitin Mehta >Assignee: Nitin Mehta > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-4201) listServiceOfferings API needs to be able to take virtualmachineid of SystemVM and return service offerings available for the vm to change service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-4201: Environment: listServiceOfferings API needs to be able to take virtualmachineid of SystemVM and returns service offerings available for the vm to change service offering. If vm is running only scale up service offering should be presented. If vm is stopped all service offering should be shown. (was: listServiceOfferings API needs to be able to take virtualmachineid of SystemVM and returns service offerings available for the vm to change service offering. If vm is running only scale up service offering should be presented. If vm is stopped all service offering should be shown) > listServiceOfferings API needs to be able to take virtualmachineid of > SystemVM and return service offerings available for the vm to change service > offering > --- > > Key: CLOUDSTACK-4201 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4201 > 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 > Environment: listServiceOfferings API needs to be able to take > virtualmachineid of SystemVM and returns service offerings available for the > vm to change service offering. If vm is running only scale up service > offering should be presented. If vm is stopped all service offering should be > shown. >Reporter: Nitin Mehta >Assignee: Nitin Mehta > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-4201) listServiceOfferings API needs to be able to take virtualmachineid of SystemVM and return service offerings available for the vm to change service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-4201: Fix Version/s: (was: 4.6.0) 4.5.0 > listServiceOfferings API needs to be able to take virtualmachineid of > SystemVM and return service offerings available for the vm to change service > offering > --- > > Key: CLOUDSTACK-4201 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4201 > 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 > Environment: listServiceOfferings API needs to be able to take > virtualmachineid of SystemVM and returns service offerings available for the > vm to change service offering. If vm is running only scale up service > offering should be presented. If vm is stopped all service offering should be > shown. >Reporter: Nitin Mehta >Assignee: Nitin Mehta > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7539) [S3] Parallel deployment makes reference count of a cache in nfs secondary staging store negative(-1)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14175827#comment-14175827
]
Francois Gaudreault commented on CLOUDSTACK-7539:
-
We are hitting the same bug with swift, but only on one specific template. We
also see some weird behaviour with the template being cached in a directory
instead of a file...
Have you found a workaround?
We use 4.4.1.
> [S3] Parallel deployment makes reference count of a cache in nfs secondary
> staging store negative(-1)
> -
>
> Key: CLOUDSTACK-7539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7539
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Template
>Affects Versions: Future, 4.3.0, 4.4.0, 4.5.0
> Environment: OS: CentOS 6.5, CloudStack Version: 4.3.0, Hypervisor:
> KVM, Primary Storage: Local Storage, Secondary Storage: S3(RADOS), Zone:
> Advanced
>Reporter: Hiroki Ohashi
>Priority: Critical
>
> When we create some instances in parallel in an environment shown above, an
> exception like ([#2]) happens. After that, reference count of a cache in NFS
> Secondary Staging Store(SSS) becomes negative([#3]).
> In this situcation, we can't use a template used for creating the instances
> because negative reference count will cause another
> exception([#4]). Furthermore, template caches in NFS SSS aren't cleaned up.
> I think this is related to CLOUDSTACK-6236. I'm using CloudStack 4.3.0
> branch. The code was applied a patch of CLOUDSTACK-6236 to and also fixed
> about volume reference count setter problem by myself. But the reference
> count problem still happens.
> Conditions to trigger
> - A cache of a template isn't on NFS SSS.
> - Choose compute offering that occupies all resources in a host.(ex. Use
> all cores and almost all memory)
> - Create multiple instances ([#1]).
> Other behaviors
> - Management server inserts multiple entries for template cache(ImageCache)
> to cloud.template_store_ref.
> - SSVM probably downloads same template from S3 and creates multiple caches
> to NFS SSS concurrently. Sometimes, SSVM retries download and cache creation.
> (1)
> {anchor:1}
> {noformat}
> #! /bin/bash
> COMPUTE_OFFERING="b6fc0598-6903-48cc-b894-ead3bb0e39f5"
> TEMPLATE="ef1d5a8e-5951-4036-a236-fe2d47224fe4"
> ZONE="23156857-4722-4fc4-86d4-a12ca1028197"
> NETWORK="4ba56179-f7b9-4560-a00e-80c946856ff8"
> KEYPAIR=mykey
> NAME1="test-template-error-0003"
> NAME2="test-template-error-0004"
> cloudmonkey deploy virtualmachine serviceofferingid=${COMPUTE_OFFERING}
> templateid=${TEMPLATE} zoneid=${ZONE} networkids=${NETWORK}
> displayname=${NAME1} name=${NAME1} keypair=${KEYPAIR}
> sleep 1
> cloudmonkey deploy virtualmachine serviceofferingid=${COMPUTE_OFFERING}
> templateid=${TEMPLATE} zoneid=${ZONE} networkids=${NETWORK}
> displayname=${NAME2} name=${NAME2} keypair=${KEYPAIR}
> {noformat}
> (2)
> {anchor:2}
> {noformat}
> 2014-09-10 17:22:51,249 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null)
> Seq 171-1789133096: Processing: { Ans: , MgmtId: 98532524288, via: 171, Ver:
> v1, Flags: 10,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"newData":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/3/330/22e69a40-0916-4d11-a07a-63d38e76887f.qcow2","id":0,"accountId":0,"hvm":false,"name":"22e69a40-0916-4d11-a07a-63d38e76887f.qcow2","size":14340259840,"physicalSize":14340259840}},"result":true,"wait":0}}]
> }
> 2014-09-10 17:22:51,249 DEBUG [c.c.a.t.Request]
> (Job-Executor-162:ctx-4a2eb345 ctx-fbf59f27) Seq 171-1789133096: Received: {
> Ans: , MgmtId: 98532524288, via: 171, Ver: v1, Flags: 10, { CopyCmdAnswer } }
> 2014-09-10 17:22:51,257 DEBUG [o.a.c.s.i.s.TemplateObject]
> (Job-Executor-162:ctx-4a2eb345 ctx-fbf59f27) failed to update state
> com.cloud.utils.fsm.NoTransitionException: Unable to transition to a new
> state from Allocated via OperationSuccessed
> at
> com.cloud.utils.fsm.StateMachine2.getNextState(StateMachine2.java:83)
> at com.cloud.utils.fsm.StateMachine2.transitTo(StateMachine2.java:100)
> at
> org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.update(ObjectInDataStoreManagerImpl.java:297)
> at
> org.apache.cloudstack.storage.image.store.TemplateObject.processEvent(TemplateObject.java:225)
> at
> org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.createCacheObject(StorageCacheManagerImpl.java:240)
> at
> org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.createCacheObject(StorageCacheManagerImpl.java:267)
>
