[jira] [Created] (CLOUDSTACK-8101) volume sync not working as expected - MS restart during upload volume leaves volume in hung state
Min Chen created CLOUDSTACK-8101: Summary: volume sync not working as expected - MS restart during upload volume leaves volume in hung state Key: CLOUDSTACK-8101 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8101 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.5.0 Steps: = Create a cluster with ESXi Start upload volume While in progress, restart MS Watch logs and monitor status of the volume Result == Volume remains in half uploaded state even after restart of MS / SSVM. We have to upload it again, but the existing one cannot be deleted. (except directly from the DB). VolumeSync should try to re-download the failed upload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8101) volume sync not working as expected - MS restart during upload volume leaves volume in hung state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254400#comment-14254400 ] Min Chen commented on CLOUDSTACK-8101: -- Commit e559b15b6a166e2eb5f9b044338295fe8c9d219d is no need to port to 4.5 since c5d3a73c67056048c9640f16730bc5929627d486 in 4.5 has already had that fix. volume sync not working as expected - MS restart during upload volume leaves volume in hung state - Key: CLOUDSTACK-8101 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8101 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.5.0 Steps: = Create a cluster with ESXi Start upload volume While in progress, restart MS Watch logs and monitor status of the volume Result == Volume remains in half uploaded state even after restart of MS / SSVM. We have to upload it again, but the existing one cannot be deleted. (except directly from the DB). VolumeSync should try to re-download the failed upload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8101) volume sync not working as expected - MS restart during upload volume leaves volume in hung state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-8101. -- Resolution: Fixed volume sync not working as expected - MS restart during upload volume leaves volume in hung state - Key: CLOUDSTACK-8101 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8101 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.5.0 Steps: = Create a cluster with ESXi Start upload volume While in progress, restart MS Watch logs and monitor status of the volume Result == Volume remains in half uploaded state even after restart of MS / SSVM. We have to upload it again, but the existing one cannot be deleted. (except directly from the DB). VolumeSync should try to re-download the failed upload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8093) Not able to list shared templates by passing id.
Min Chen created CLOUDSTACK-8093:
Summary: Not able to list shared templates by passing id.
Key: CLOUDSTACK-8093
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8093
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: IAM
Affects Versions: 4.4.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
Steps to reproduce the problem:
Create user test and testa under ROOT domain.
Register a private template T1 as user test.
Update Template permission to ass user testa for this template - T1.
As testa , list the details of this template by passing its Id:
This action is not permitted:
http://localhost:8080/client/api?command=listTemplatesresponse=jsonsessionkey=qVqJ8mbFV8EsjE9vKoCydIaP0BM%3Dtemplatefilter=selfid=cb0dd33f-3a0d-49fb-bf1f-0b6c15ad1455_=1418851061799
{ listtemplatesresponse :
{uuidList:[],errorcode:531,cserrorcode:4365,errortext:Acct[bdee8701-0495-4140-8823-25d56723082d-test-b]
does not have permission to operate with resource
Acct[cc0f203d-4018-470e-85f8-44105a7d182e-test-a]}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8093) Not able to list shared templates by passing id.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252035#comment-14252035
]
Min Chen commented on CLOUDSTACK-8093:
--
Fixed it by properly checking template permission when id is passed
Not able to list shared templates by passing id.
Key: CLOUDSTACK-8093
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8093
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: IAM
Affects Versions: 4.4.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
Steps to reproduce the problem:
Create user test and testa under ROOT domain.
Register a private template T1 as user test.
Update Template permission to ass user testa for this template - T1.
As testa , list the details of this template by passing its Id:
This action is not permitted:
http://localhost:8080/client/api?command=listTemplatesresponse=jsonsessionkey=qVqJ8mbFV8EsjE9vKoCydIaP0BM%3Dtemplatefilter=selfid=cb0dd33f-3a0d-49fb-bf1f-0b6c15ad1455_=1418851061799
{ listtemplatesresponse :
{uuidList:[],errorcode:531,cserrorcode:4365,errortext:Acct[bdee8701-0495-4140-8823-25d56723082d-test-b]
does not have permission to operate with resource
Acct[cc0f203d-4018-470e-85f8-44105a7d182e-test-a]}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8093) Not able to list shared templates by passing id.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-8093.
--
Resolution: Fixed
Not able to list shared templates by passing id.
Key: CLOUDSTACK-8093
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8093
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: IAM
Affects Versions: 4.4.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
Steps to reproduce the problem:
Create user test and testa under ROOT domain.
Register a private template T1 as user test.
Update Template permission to ass user testa for this template - T1.
As testa , list the details of this template by passing its Id:
This action is not permitted:
http://localhost:8080/client/api?command=listTemplatesresponse=jsonsessionkey=qVqJ8mbFV8EsjE9vKoCydIaP0BM%3Dtemplatefilter=selfid=cb0dd33f-3a0d-49fb-bf1f-0b6c15ad1455_=1418851061799
{ listtemplatesresponse :
{uuidList:[],errorcode:531,cserrorcode:4365,errortext:Acct[bdee8701-0495-4140-8823-25d56723082d-test-b]
does not have permission to operate with resource
Acct[cc0f203d-4018-470e-85f8-44105a7d182e-test-a]}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8077) Not able to deploy VM using a shared template.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-8077. -- Resolution: Fixed Not able to deploy VM using a shared template. -- Key: CLOUDSTACK-8077 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8077 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Steps to reproduce the problem: Create 2 users under ROOT - san1 and san2 As san1: 1. Register a template(private) 2. Update template permission , so that it is shared with san2. 3. Listing template permission , shows that this template is shared with san2. 4. As san2 , Listing templates with templatefilter=shared , lists template test1 that was shared with san2. 5. As use san2 , try to deploy VM using the shared template - test1. This errors out following error message and return code- 531 Acct[c4c843e4-98a4-4384-9410-281243dfaa88-san2] does not have permission to operate with resource Acct[08dd8e5e-bb06-40fc-9a94-9eed073a358a-san1] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8077) Not able to deploy VM using a shared template.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14250342#comment-14250342 ] Min Chen commented on CLOUDSTACK-8077: -- In service layer, we incorrectly perform template permission check by checking if VM owner has permission to the template owner, which caused the error. Instead we should perform permission by checking if VM owner has permission to the template. Fixed with above commit. Not able to deploy VM using a shared template. -- Key: CLOUDSTACK-8077 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8077 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Steps to reproduce the problem: Create 2 users under ROOT - san1 and san2 As san1: 1. Register a template(private) 2. Update template permission , so that it is shared with san2. 3. Listing template permission , shows that this template is shared with san2. 4. As san2 , Listing templates with templatefilter=shared , lists template test1 that was shared with san2. 5. As use san2 , try to deploy VM using the shared template - test1. This errors out following error message and return code- 531 Acct[c4c843e4-98a4-4384-9410-281243dfaa88-san2] does not have permission to operate with resource Acct[08dd8e5e-bb06-40fc-9a94-9eed073a358a-san1] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-315) Infrastructure view does not show capacity values
[ https://issues.apache.org/jira/browse/CLOUDSTACK-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-315. - Resolution: Fixed This has already been fixed with count statistis returned in our list API. Infrastructure view does not show capacity values - Key: CLOUDSTACK-315 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-315 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.1.0, 4.2.0 Environment: master branch Reporter: Rohit Yadav Assignee: Min Chen Priority: Minor Fix For: 4.5.0, 4.4.3 Goto Infrastructure, it won't post a GET request to get list of capacities, no. of hosts, zones, routers etc.; and fails to show any capacity values. This was observed on master branch, head=16fa74b7293039db75fdc6851c35e194b33f2135. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-315) Infrastructure view does not show capacity values
[ https://issues.apache.org/jira/browse/CLOUDSTACK-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14250380#comment-14250380 ] Min Chen edited comment on CLOUDSTACK-315 at 12/17/14 7:39 PM: --- This has already been fixed with count statistics returned in our list API. was (Author: minchen07): This has already been fixed with count statistis returned in our list API. Infrastructure view does not show capacity values - Key: CLOUDSTACK-315 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-315 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.1.0, 4.2.0 Environment: master branch Reporter: Rohit Yadav Assignee: Min Chen Priority: Minor Fix For: 4.5.0, 4.4.3 Goto Infrastructure, it won't post a GET request to get list of capacities, no. of hosts, zones, routers etc.; and fails to show any capacity values. This was observed on master branch, head=16fa74b7293039db75fdc6851c35e194b33f2135. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8061) Extracting volume when it is in migrating state causes both the operations to fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-8061. -- Resolution: Fixed Extracting volume when it is in migrating state causes both the operations to fail -- Key: CLOUDSTACK-8061 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8061 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Extracting volume when it is in migrating state causes both the operations to fail Steps to Reproduce: 1.Bring up CloudStack in advanced zone with xen cluster 2.Add two shared cluster level primary stores to the cluster 3.Deploy one vm using the default cent os template 4.Stop the vm 5.Migrate volume to another shared store 6.When the volume is in migrating state try to download the same volume. We will not see extract volume option in UI while volume is in migrating state. So please do it using API: http:/host:8096/client/api?command=extractVolumeid=03f4a082-a96c-4195-b74b-7aa602926825zoneid=f6c57314-d7df-417e-b994-c4a7c4e5b557mode=HTTP_DOWNLOAD Expected Behavior: If there is a race condition either of this operation should succeed. Or ExtractVolume job should wait for the migration job to finish and then execute extractvolume. Actual Behavior: = Both the operations are failed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8061) Extracting volume when it is in migrating state causes both the operations to fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14249206#comment-14249206 ] Min Chen commented on CLOUDSTACK-8061: -- Problem: Executing MigrateVolume and ExtractVolume in parallel caused both operations to fail. RCA: Based on new VMSync framework, volume operations working on the same VM should be serialized to avoid conflict, and this is missing for ExtractVolumeCmd. Solution: Change ExtractVolumeCmd to follow the same convention used in other VM related volume operations. Extracting volume when it is in migrating state causes both the operations to fail -- Key: CLOUDSTACK-8061 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8061 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Extracting volume when it is in migrating state causes both the operations to fail Steps to Reproduce: 1.Bring up CloudStack in advanced zone with xen cluster 2.Add two shared cluster level primary stores to the cluster 3.Deploy one vm using the default cent os template 4.Stop the vm 5.Migrate volume to another shared store 6.When the volume is in migrating state try to download the same volume. We will not see extract volume option in UI while volume is in migrating state. So please do it using API: http:/host:8096/client/api?command=extractVolumeid=03f4a082-a96c-4195-b74b-7aa602926825zoneid=f6c57314-d7df-417e-b994-c4a7c4e5b557mode=HTTP_DOWNLOAD Expected Behavior: If there is a race condition either of this operation should succeed. Or ExtractVolume job should wait for the migration job to finish and then execute extractvolume. Actual Behavior: = Both the operations are failed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8077) Not able to deploy VM using a shared template.
Min Chen created CLOUDSTACK-8077: Summary: Not able to deploy VM using a shared template. Key: CLOUDSTACK-8077 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8077 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Steps to reproduce the problem: Create 2 users under ROOT - san1 and san2 As san1: 1. Register a template(private) 2. Update template permission , so that it is shared with san2. 3. Listing template permission , shows that this template is shared with san2. 4. As san2 , Listing templates with templatefilter=shared , lists template test1 that was shared with san2. 5. As use san2 , try to deploy VM using the shared template - test1. This errors out following error message and return code- 531 Acct[c4c843e4-98a4-4384-9410-281243dfaa88-san2] does not have permission to operate with resource Acct[08dd8e5e-bb06-40fc-9a94-9eed073a358a-san1] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8061) Extracting volume when it is in migrating state causes both the operations to fail
Min Chen created CLOUDSTACK-8061: Summary: Extracting volume when it is in migrating state causes both the operations to fail Key: CLOUDSTACK-8061 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8061 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Extracting volume when it is in migrating state causes both the operations to fail Steps to Reproduce: 1.Bring up CloudStack in advanced zone with xen cluster 2.Add two shared cluster level primary stores to the cluster 3.Deploy one vm using the default cent os template 4.Stop the vm 5.Migrate volume to another shared store 6.When the volume is in migrating state try to download the same volume. We will not see extract volume option in UI while volume is in migrating state. So please do it using API: http:/host:8096/client/api?command=extractVolumeid=03f4a082-a96c-4195-b74b-7aa602926825zoneid=f6c57314-d7df-417e-b994-c4a7c4e5b557mode=HTTP_DOWNLOAD Expected Behavior: If there is a race condition either of this operation should succeed. Or ExtractVolume job should wait for the migration job to finish and then execute extractvolume. Actual Behavior: = Both the operations are failed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7968) [Automation] ListVirtualMachines failed due to NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen updated CLOUDSTACK-7968:
-
Description:
==
NullPointer Exception:
==
{noformat}
2014-11-25 07:02:04,577 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-3c4583df) ===START=== 10.220.135.158 -- GET
apiKey=cZnc5GpyJx80LGvhVhQMwdCSfoIyzyVRq1F4lRjI00w1xrAgCOTAZWpxgtARH_JNID8RSYjGnJalpQcy5u1Xfgcommand=listVirtualMachinessignature=5T4zh0Tv4tnLOFRwNn8DRghnJkA%3Dtags%5B0%5D.key=region111response=jsonlistall=Truetags%5B0%5D.value=India
2014-11-25 07:02:04,600 ERROR [c.c.a.ApiServer] (catalina-exec-22:ctx-3c4583df
ctx-8f125542 ctx-2cc1f4d0) unhandled exception executing api command:
[Ljava.lang.String;@7bf2b28
com.cloud.utils.exception.CloudRuntimeException: Caught:
com.mysql.jdbc.JDBC4PreparedStatement@235185cf: SELECT
DISTINCT(user_vm_view.id) FROM user_vm_view WHERE user_vm_view.account_type !=
5 AND user_vm_view.display_vm = 1 AND ( ( AND ) ) AND user_vm_view.removed
IS NULL ORDER BY user_vm_view.id ASC LIMIT 0, 1
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:427)
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:361)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:345)
at
com.cloud.utils.db.GenericDaoBase.searchAndCount(GenericDaoBase.java:1296)
at sun.reflect.GeneratedMethodAccessor132.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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 $Proxy175.searchAndCount(Unknown Source)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMsInternal(QueryManagerImpl.java:996)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMs(QueryManagerImpl.java:756)
at
org.apache.cloudstack.api.command.user.vm.ListVMsCmd.execute(ListVMsCmd.java:227)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:691)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:514)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:276)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:120)
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:117)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:79)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at
org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
at
[jira] [Comment Edited] (CLOUDSTACK-7968) [Automation] ListVirtualMachines failed due to NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234788#comment-14234788
]
Min Chen edited comment on CLOUDSTACK-7968 at 12/4/14 11:34 PM:
Found the problem, and fixed by commit
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=4e7af26c9fcdb3914c577c743fd83c8f7b8ef424.
This only impacts listVM search by resource tags. It is caused by listVM
performance optimization done in commit
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=4e7af26c9fcdb3914c577c743fd83c8f7b8ef424.
was (Author: minchen07):
Found the problem, and fixed by commit
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=4e7af26c9fcdb3914c577c743fd83c8f7b8ef424.
[Automation] ListVirtualMachines failed due to NPE
--
Key: CLOUDSTACK-7968
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7968
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: Chandan Purushothama
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
==
NullPointer Exception:
==
{noformat}
2014-11-25 07:02:04,577 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-3c4583df) ===START=== 10.220.135.158 -- GET
apiKey=cZnc5GpyJx80LGvhVhQMwdCSfoIyzyVRq1F4lRjI00w1xrAgCOTAZWpxgtARH_JNID8RSYjGnJalpQcy5u1Xfgcommand=listVirtualMachinessignature=5T4zh0Tv4tnLOFRwNn8DRghnJkA%3Dtags%5B0%5D.key=region111response=jsonlistall=Truetags%5B0%5D.value=India
2014-11-25 07:02:04,600 ERROR [c.c.a.ApiServer]
(catalina-exec-22:ctx-3c4583df ctx-8f125542 ctx-2cc1f4d0) unhandled exception
executing api command: [Ljava.lang.String;@7bf2b28
com.cloud.utils.exception.CloudRuntimeException: Caught:
com.mysql.jdbc.JDBC4PreparedStatement@235185cf: SELECT
DISTINCT(user_vm_view.id) FROM user_vm_view WHERE user_vm_view.account_type
!= 5 AND user_vm_view.display_vm = 1 AND ( ( AND ) ) AND
user_vm_view.removed IS NULL ORDER BY user_vm_view.id ASC LIMIT 0, 1
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:427)
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:361)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:345)
at
com.cloud.utils.db.GenericDaoBase.searchAndCount(GenericDaoBase.java:1296)
at sun.reflect.GeneratedMethodAccessor132.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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 $Proxy175.searchAndCount(Unknown Source)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMsInternal(QueryManagerImpl.java:996)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMs(QueryManagerImpl.java:756)
at
org.apache.cloudstack.api.command.user.vm.ListVMsCmd.execute(ListVMsCmd.java:227)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:691)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:514)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:276)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:120)
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:117)
at
[jira] [Reopened] (CLOUDSTACK-7968) [Automation] ListVirtualMachines failed due to NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen reopened CLOUDSTACK-7968:
--
[Automation] ListVirtualMachines failed due to NPE
--
Key: CLOUDSTACK-7968
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7968
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: Chandan Purushothama
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
==
NullPointer Exception:
==
{noformat}
2014-11-25 07:02:04,577 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-3c4583df) ===START=== 10.220.135.158 -- GET
apiKey=cZnc5GpyJx80LGvhVhQMwdCSfoIyzyVRq1F4lRjI00w1xrAgCOTAZWpxgtARH_JNID8RSYjGnJalpQcy5u1Xfgcommand=listVirtualMachinessignature=5T4zh0Tv4tnLOFRwNn8DRghnJkA%3Dtags%5B0%5D.key=region111response=jsonlistall=Truetags%5B0%5D.value=India
2014-11-25 07:02:04,600 ERROR [c.c.a.ApiServer]
(catalina-exec-22:ctx-3c4583df ctx-8f125542 ctx-2cc1f4d0) unhandled exception
executing api command: [Ljava.lang.String;@7bf2b28
com.cloud.utils.exception.CloudRuntimeException: Caught:
com.mysql.jdbc.JDBC4PreparedStatement@235185cf: SELECT
DISTINCT(user_vm_view.id) FROM user_vm_view WHERE user_vm_view.account_type
!= 5 AND user_vm_view.display_vm = 1 AND ( ( AND ) ) AND
user_vm_view.removed IS NULL ORDER BY user_vm_view.id ASC LIMIT 0, 1
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:427)
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:361)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:345)
at
com.cloud.utils.db.GenericDaoBase.searchAndCount(GenericDaoBase.java:1296)
at sun.reflect.GeneratedMethodAccessor132.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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 $Proxy175.searchAndCount(Unknown Source)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMsInternal(QueryManagerImpl.java:996)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMs(QueryManagerImpl.java:756)
at
org.apache.cloudstack.api.command.user.vm.ListVMsCmd.execute(ListVMsCmd.java:227)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:691)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:514)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:276)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:120)
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:117)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:79)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
[jira] [Resolved] (CLOUDSTACK-7968) [Automation] ListVirtualMachines failed due to NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-7968.
--
Resolution: Fixed
[Automation] ListVirtualMachines failed due to NPE
--
Key: CLOUDSTACK-7968
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7968
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: Chandan Purushothama
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
==
NullPointer Exception:
==
{noformat}
2014-11-25 07:02:04,577 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-3c4583df) ===START=== 10.220.135.158 -- GET
apiKey=cZnc5GpyJx80LGvhVhQMwdCSfoIyzyVRq1F4lRjI00w1xrAgCOTAZWpxgtARH_JNID8RSYjGnJalpQcy5u1Xfgcommand=listVirtualMachinessignature=5T4zh0Tv4tnLOFRwNn8DRghnJkA%3Dtags%5B0%5D.key=region111response=jsonlistall=Truetags%5B0%5D.value=India
2014-11-25 07:02:04,600 ERROR [c.c.a.ApiServer]
(catalina-exec-22:ctx-3c4583df ctx-8f125542 ctx-2cc1f4d0) unhandled exception
executing api command: [Ljava.lang.String;@7bf2b28
com.cloud.utils.exception.CloudRuntimeException: Caught:
com.mysql.jdbc.JDBC4PreparedStatement@235185cf: SELECT
DISTINCT(user_vm_view.id) FROM user_vm_view WHERE user_vm_view.account_type
!= 5 AND user_vm_view.display_vm = 1 AND ( ( AND ) ) AND
user_vm_view.removed IS NULL ORDER BY user_vm_view.id ASC LIMIT 0, 1
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:427)
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:361)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:345)
at
com.cloud.utils.db.GenericDaoBase.searchAndCount(GenericDaoBase.java:1296)
at sun.reflect.GeneratedMethodAccessor132.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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 $Proxy175.searchAndCount(Unknown Source)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMsInternal(QueryManagerImpl.java:996)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMs(QueryManagerImpl.java:756)
at
org.apache.cloudstack.api.command.user.vm.ListVMsCmd.execute(ListVMsCmd.java:227)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:691)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:514)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:276)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:120)
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:117)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:79)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
[jira] [Assigned] (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:all-tabpanel
]
Min Chen reassigned CLOUDSTACK-7539:
Assignee: Min Chen
[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
Assignee: Min Chen
Priority: Critical
Fix For: Future, 4.5.0, 4.6.0, 4.4.3, 4.3.2
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)
at
org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyObject(AncientDataMotionStrategy.java:165)
at
org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:428)
at
[jira] [Updated] (CLOUDSTACK-5920) CloudStack IAM Plugin feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen updated CLOUDSTACK-5920: - Fix Version/s: (was: 4.5.0) Future CloudStack IAM Plugin feature - Key: CLOUDSTACK-5920 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5920 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.3.0 Reporter: Prachi Damle Assignee: Prachi Damle Fix For: Future Currently CloudStack provides very limited IAM services and there are several drawbacks within those services: - Offers few roles out of the box (user and admin) with prebaked access control for these roles. There is no way to create additional roles with customized permissions. - Some resources have access control baked into them. E.g., shared networks, projects etc. - We have to create special dedicate APIs to grant permissions to resources. - Also it should be based on a plugin model to be possible to integrate with other RBAC implementations say using AD/LDAP in future Goal for this feature would be to address these limitations and offer true IAM services in a phased manner. As a first phase, we need to separate out the current access control into a separate component and create a standard access check mechanism to be used by the API layer. Also the read/listing APIs need to be refactored accordingly to consider the role based access granting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7968) [Automation] ListVirtualMachines failed due to NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-7968.
--
Resolution: Incomplete
[Automation] ListVirtualMachines failed due to NPE
--
Key: CLOUDSTACK-7968
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7968
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: Chandan Purushothama
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
==
NullPointer Exception:
==
{noformat}
2014-11-25 07:02:04,577 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-3c4583df) ===START=== 10.220.135.158 -- GET
apiKey=cZnc5GpyJx80LGvhVhQMwdCSfoIyzyVRq1F4lRjI00w1xrAgCOTAZWpxgtARH_JNID8RSYjGnJalpQcy5u1Xfgcommand=listVirtualMachinessignature=5T4zh0Tv4tnLOFRwNn8DRghnJkA%3Dtags%5B0%5D.key=region111response=jsonlistall=Truetags%5B0%5D.value=India
2014-11-25 07:02:04,600 ERROR [c.c.a.ApiServer]
(catalina-exec-22:ctx-3c4583df ctx-8f125542 ctx-2cc1f4d0) unhandled exception
executing api command: [Ljava.lang.String;@7bf2b28
com.cloud.utils.exception.CloudRuntimeException: Caught:
com.mysql.jdbc.JDBC4PreparedStatement@235185cf: SELECT
DISTINCT(user_vm_view.id) FROM user_vm_view WHERE user_vm_view.account_type
!= 5 AND user_vm_view.display_vm = 1 AND ( ( AND ) ) AND
user_vm_view.removed IS NULL ORDER BY user_vm_view.id ASC LIMIT 0, 1
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:427)
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:361)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:345)
at
com.cloud.utils.db.GenericDaoBase.searchAndCount(GenericDaoBase.java:1296)
at sun.reflect.GeneratedMethodAccessor132.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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 $Proxy175.searchAndCount(Unknown Source)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMsInternal(QueryManagerImpl.java:996)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMs(QueryManagerImpl.java:756)
at
org.apache.cloudstack.api.command.user.vm.ListVMsCmd.execute(ListVMsCmd.java:227)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:691)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:514)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:276)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:120)
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:117)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:79)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
[jira] [Commented] (CLOUDSTACK-7968) [Automation] ListVirtualMachines failed due to NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230796#comment-14230796
]
Min Chen commented on CLOUDSTACK-7968:
--
Please attach the db dump for investigation.
[Automation] ListVirtualMachines failed due to NPE
--
Key: CLOUDSTACK-7968
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7968
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: Chandan Purushothama
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
==
NullPointer Exception:
==
{noformat}
2014-11-25 07:02:04,577 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-3c4583df) ===START=== 10.220.135.158 -- GET
apiKey=cZnc5GpyJx80LGvhVhQMwdCSfoIyzyVRq1F4lRjI00w1xrAgCOTAZWpxgtARH_JNID8RSYjGnJalpQcy5u1Xfgcommand=listVirtualMachinessignature=5T4zh0Tv4tnLOFRwNn8DRghnJkA%3Dtags%5B0%5D.key=region111response=jsonlistall=Truetags%5B0%5D.value=India
2014-11-25 07:02:04,600 ERROR [c.c.a.ApiServer]
(catalina-exec-22:ctx-3c4583df ctx-8f125542 ctx-2cc1f4d0) unhandled exception
executing api command: [Ljava.lang.String;@7bf2b28
com.cloud.utils.exception.CloudRuntimeException: Caught:
com.mysql.jdbc.JDBC4PreparedStatement@235185cf: SELECT
DISTINCT(user_vm_view.id) FROM user_vm_view WHERE user_vm_view.account_type
!= 5 AND user_vm_view.display_vm = 1 AND ( ( AND ) ) AND
user_vm_view.removed IS NULL ORDER BY user_vm_view.id ASC LIMIT 0, 1
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:427)
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:361)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:345)
at
com.cloud.utils.db.GenericDaoBase.searchAndCount(GenericDaoBase.java:1296)
at sun.reflect.GeneratedMethodAccessor132.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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 $Proxy175.searchAndCount(Unknown Source)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMsInternal(QueryManagerImpl.java:996)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMs(QueryManagerImpl.java:756)
at
org.apache.cloudstack.api.command.user.vm.ListVMsCmd.execute(ListVMsCmd.java:227)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:691)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:514)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:276)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:120)
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:117)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:79)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
[jira] [Created] (CLOUDSTACK-7981) listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view
Min Chen created CLOUDSTACK-7981: Summary: listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view Key: CLOUDSTACK-7981 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7981 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Deploy 40 to 50 VMs, each one has 3-4 resource tags, and each one also add about 10 details, then do a listVMCmd, the performance is very slow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7981) listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227123#comment-14227123 ] Min Chen commented on CLOUDSTACK-7981: -- we should not join user_vm_details table in user_vm_view at all since our code never used them, we always find details from user_vm_details table directly. Also, handle duplicate resource tag entry by avoiding retrieving duplicate tags. listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view Key: CLOUDSTACK-7981 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7981 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Deploy 40 to 50 VMs, each one has 3-4 resource tags, and each one also add about 10 details, then do a listVMCmd, the performance is very slow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7981) listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7981. -- Resolution: Fixed listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view Key: CLOUDSTACK-7981 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7981 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Deploy 40 to 50 VMs, each one has 3-4 resource tags, and each one also add about 10 details, then do a listVMCmd, the performance is very slow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7678) volumes are getting uploaded successfully with wrong url
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen reassigned CLOUDSTACK-7678:
Assignee: Min Chen (was: Nitin Mehta)
volumes are getting uploaded successfully with wrong url
-
Key: CLOUDSTACK-7678
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7678
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: prashant kumar mishra
Assignee: Min Chen
Fix For: 4.5.0
Attachments: Logs_Db.rar
steps to reproduce
-
try to upload a volume with wrong url
(ex:http://10.147.28.7/templates/4.2/systemvmtemplate-4.2-vh7.wrong.ova)
expected
upload volume should fail with error message
actual
volume got uploaded without any error ;volume state=Allocated ,status=empty
LOG
2014-10-07 14:06:28,065 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-10:ctx-e194f749 ctx-d4dd2a52) submit async job-578, details:
AsyncJobVO {id:578, userId: 2, accountId: 2, instanceType: None, instanceId:
null, cmd:
org.apache.cloudstack.api.command.admin.volume.UploadVolumeCmdByAdmin,
cmdInfo:
{sessionkey:O23XzQurR1dEYRv5vCw7aueeRKo\u003d,cmdEventType:VOLUME.UPLOAD,ctxUserId:2,httpmethod:GET,format:OVA,url:http://10.147.28.7/templates/4.2/systemvmtemplate-4.2-vh7.wrong.ova,zoneId:41d605d3-1f77-4878-9559-4710a3b1a8f4,response:json,ctxDetails:{\com.cloud.dc.DataCenter\:\41d605d3-1f77-4878-9559-4710a3b1a8f4\},name:vol,_:1412670977063,ctxAccountId:2,ctxStartEventId:982},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7407677735140, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-10-07 14:06:28,067 DEBUG [c.c.a.ApiServlet]
(catalina-exec-10:ctx-e194f749 ctx-d4dd2a52) ===END=== 10.252.193.17 -- GET
command=uploadVolumeresponse=jsonsessionkey=O23XzQurR1dEYRv5vCw7aueeRKo%3Dname=volzoneId=41d605d3-1f77-4878-9559-4710a3b1a8f4format=OVAurl=http%3A%2F%2F10.147.28.7%2Ftemplates%2F4.2%2Fsystemvmtemplate-4.2-vh7.wrong.ova_=1412670977063
2014-10-07 14:06:28,082 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-47:ctx-af7d36d6 job-578) Add job-578 into job monitoring
2014-10-07 14:06:28,082 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-47:ctx-af7d36d6 job-578) Executing AsyncJobVO {id:578,
userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.volume.UploadVolumeCmdByAdmin,
cmdInfo:
{sessionkey:O23XzQurR1dEYRv5vCw7aueeRKo\u003d,cmdEventType:VOLUME.UPLOAD,ctxUserId:2,httpmethod:GET,format:OVA,url:http://10.147.28.7/templates/4.2/systemvmtemplate-4.2-vh7.wrong.ova,zoneId:41d605d3-1f77-4878-9559-4710a3b1a8f4,response:json,ctxDetails:{\com.cloud.dc.DataCenter\:\41d605d3-1f77-4878-9559-4710a3b1a8f4\},name:vol,_:1412670977063,ctxAccountId:2,ctxStartEventId:982},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7407677735140, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-10-07 14:06:28,250 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgentCronJob-436:ctx-fb02db4a) Ping from 1(10.147.40.11)
2014-10-07 14:06:28,251 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Process host VM state report from ping
process. host: 1
2014-10-07 14:06:28,255 INFO [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Unable to find matched VM in CloudStack
DB. name: i-4-20-VM
2014-10-07 14:06:28,258 INFO [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Unable to find matched VM in CloudStack
DB. name: i-4-40-VM
2014-10-07 14:06:28,277 INFO [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Unable to find matched VM in CloudStack
DB. name: i-4-42-VM
2014-10-07 14:06:28,323 INFO [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Unable to find matched VM in CloudStack
DB. name: fa4150b3b46f4386862d37b942a07ca7
2014-10-07 14:06:28,401 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Process VM state report. host: 1,
number of records in report: 7
2014-10-07 14:06:28,404 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) VM state report. host: 1, vm id: 1,
power state: PowerOn
2014-10-07 14:06:28,419 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) VM power state does not change, skip DB
writing. vm id: 1
2014-10-07 14:06:28,419 DEBUG
[jira] [Commented] (CLOUDSTACK-7678) volumes are getting uploaded successfully with wrong url
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221565#comment-14221565
]
Min Chen commented on CLOUDSTACK-7678:
--
Before persisting volume in DB, we also use HTTP HEAD method to check if URL is
inaccessible. If so, report error, and no entry is created and no success job
is returned.
volumes are getting uploaded successfully with wrong url
-
Key: CLOUDSTACK-7678
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7678
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: prashant kumar mishra
Assignee: Min Chen
Fix For: 4.5.0
Attachments: Logs_Db.rar
steps to reproduce
-
try to upload a volume with wrong url
(ex:http://10.147.28.7/templates/4.2/systemvmtemplate-4.2-vh7.wrong.ova)
expected
upload volume should fail with error message
actual
volume got uploaded without any error ;volume state=Allocated ,status=empty
LOG
2014-10-07 14:06:28,065 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-10:ctx-e194f749 ctx-d4dd2a52) submit async job-578, details:
AsyncJobVO {id:578, userId: 2, accountId: 2, instanceType: None, instanceId:
null, cmd:
org.apache.cloudstack.api.command.admin.volume.UploadVolumeCmdByAdmin,
cmdInfo:
{sessionkey:O23XzQurR1dEYRv5vCw7aueeRKo\u003d,cmdEventType:VOLUME.UPLOAD,ctxUserId:2,httpmethod:GET,format:OVA,url:http://10.147.28.7/templates/4.2/systemvmtemplate-4.2-vh7.wrong.ova,zoneId:41d605d3-1f77-4878-9559-4710a3b1a8f4,response:json,ctxDetails:{\com.cloud.dc.DataCenter\:\41d605d3-1f77-4878-9559-4710a3b1a8f4\},name:vol,_:1412670977063,ctxAccountId:2,ctxStartEventId:982},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7407677735140, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-10-07 14:06:28,067 DEBUG [c.c.a.ApiServlet]
(catalina-exec-10:ctx-e194f749 ctx-d4dd2a52) ===END=== 10.252.193.17 -- GET
command=uploadVolumeresponse=jsonsessionkey=O23XzQurR1dEYRv5vCw7aueeRKo%3Dname=volzoneId=41d605d3-1f77-4878-9559-4710a3b1a8f4format=OVAurl=http%3A%2F%2F10.147.28.7%2Ftemplates%2F4.2%2Fsystemvmtemplate-4.2-vh7.wrong.ova_=1412670977063
2014-10-07 14:06:28,082 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-47:ctx-af7d36d6 job-578) Add job-578 into job monitoring
2014-10-07 14:06:28,082 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-47:ctx-af7d36d6 job-578) Executing AsyncJobVO {id:578,
userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.volume.UploadVolumeCmdByAdmin,
cmdInfo:
{sessionkey:O23XzQurR1dEYRv5vCw7aueeRKo\u003d,cmdEventType:VOLUME.UPLOAD,ctxUserId:2,httpmethod:GET,format:OVA,url:http://10.147.28.7/templates/4.2/systemvmtemplate-4.2-vh7.wrong.ova,zoneId:41d605d3-1f77-4878-9559-4710a3b1a8f4,response:json,ctxDetails:{\com.cloud.dc.DataCenter\:\41d605d3-1f77-4878-9559-4710a3b1a8f4\},name:vol,_:1412670977063,ctxAccountId:2,ctxStartEventId:982},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7407677735140, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-10-07 14:06:28,250 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgentCronJob-436:ctx-fb02db4a) Ping from 1(10.147.40.11)
2014-10-07 14:06:28,251 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Process host VM state report from ping
process. host: 1
2014-10-07 14:06:28,255 INFO [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Unable to find matched VM in CloudStack
DB. name: i-4-20-VM
2014-10-07 14:06:28,258 INFO [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Unable to find matched VM in CloudStack
DB. name: i-4-40-VM
2014-10-07 14:06:28,277 INFO [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Unable to find matched VM in CloudStack
DB. name: i-4-42-VM
2014-10-07 14:06:28,323 INFO [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Unable to find matched VM in CloudStack
DB. name: fa4150b3b46f4386862d37b942a07ca7
2014-10-07 14:06:28,401 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Process VM state report. host: 1,
number of records in report: 7
2014-10-07 14:06:28,404 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) VM state report. host: 1, vm id: 1,
power state: PowerOn
2014-10-07 14:06:28,419 DEBUG
[jira] [Resolved] (CLOUDSTACK-7678) volumes are getting uploaded successfully with wrong url
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-7678.
--
Resolution: Fixed
volumes are getting uploaded successfully with wrong url
-
Key: CLOUDSTACK-7678
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7678
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: prashant kumar mishra
Assignee: Min Chen
Fix For: 4.5.0
Attachments: Logs_Db.rar
steps to reproduce
-
try to upload a volume with wrong url
(ex:http://10.147.28.7/templates/4.2/systemvmtemplate-4.2-vh7.wrong.ova)
expected
upload volume should fail with error message
actual
volume got uploaded without any error ;volume state=Allocated ,status=empty
LOG
2014-10-07 14:06:28,065 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-10:ctx-e194f749 ctx-d4dd2a52) submit async job-578, details:
AsyncJobVO {id:578, userId: 2, accountId: 2, instanceType: None, instanceId:
null, cmd:
org.apache.cloudstack.api.command.admin.volume.UploadVolumeCmdByAdmin,
cmdInfo:
{sessionkey:O23XzQurR1dEYRv5vCw7aueeRKo\u003d,cmdEventType:VOLUME.UPLOAD,ctxUserId:2,httpmethod:GET,format:OVA,url:http://10.147.28.7/templates/4.2/systemvmtemplate-4.2-vh7.wrong.ova,zoneId:41d605d3-1f77-4878-9559-4710a3b1a8f4,response:json,ctxDetails:{\com.cloud.dc.DataCenter\:\41d605d3-1f77-4878-9559-4710a3b1a8f4\},name:vol,_:1412670977063,ctxAccountId:2,ctxStartEventId:982},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7407677735140, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-10-07 14:06:28,067 DEBUG [c.c.a.ApiServlet]
(catalina-exec-10:ctx-e194f749 ctx-d4dd2a52) ===END=== 10.252.193.17 -- GET
command=uploadVolumeresponse=jsonsessionkey=O23XzQurR1dEYRv5vCw7aueeRKo%3Dname=volzoneId=41d605d3-1f77-4878-9559-4710a3b1a8f4format=OVAurl=http%3A%2F%2F10.147.28.7%2Ftemplates%2F4.2%2Fsystemvmtemplate-4.2-vh7.wrong.ova_=1412670977063
2014-10-07 14:06:28,082 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-47:ctx-af7d36d6 job-578) Add job-578 into job monitoring
2014-10-07 14:06:28,082 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-47:ctx-af7d36d6 job-578) Executing AsyncJobVO {id:578,
userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.volume.UploadVolumeCmdByAdmin,
cmdInfo:
{sessionkey:O23XzQurR1dEYRv5vCw7aueeRKo\u003d,cmdEventType:VOLUME.UPLOAD,ctxUserId:2,httpmethod:GET,format:OVA,url:http://10.147.28.7/templates/4.2/systemvmtemplate-4.2-vh7.wrong.ova,zoneId:41d605d3-1f77-4878-9559-4710a3b1a8f4,response:json,ctxDetails:{\com.cloud.dc.DataCenter\:\41d605d3-1f77-4878-9559-4710a3b1a8f4\},name:vol,_:1412670977063,ctxAccountId:2,ctxStartEventId:982},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7407677735140, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-10-07 14:06:28,250 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgentCronJob-436:ctx-fb02db4a) Ping from 1(10.147.40.11)
2014-10-07 14:06:28,251 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Process host VM state report from ping
process. host: 1
2014-10-07 14:06:28,255 INFO [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Unable to find matched VM in CloudStack
DB. name: i-4-20-VM
2014-10-07 14:06:28,258 INFO [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Unable to find matched VM in CloudStack
DB. name: i-4-40-VM
2014-10-07 14:06:28,277 INFO [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Unable to find matched VM in CloudStack
DB. name: i-4-42-VM
2014-10-07 14:06:28,323 INFO [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Unable to find matched VM in CloudStack
DB. name: fa4150b3b46f4386862d37b942a07ca7
2014-10-07 14:06:28,401 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) Process VM state report. host: 1,
number of records in report: 7
2014-10-07 14:06:28,404 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) VM state report. host: 1, vm id: 1,
power state: PowerOn
2014-10-07 14:06:28,419 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl]
(DirectAgentCronJob-436:ctx-fb02db4a) VM power state does not change, skip DB
writing. vm id: 1
2014-10-07 14:06:28,419 DEBUG
[jira] [Assigned] (CLOUDSTACK-7954) ListTags API is ignoring the resourceID and displaying all the tags of all resources
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen reassigned CLOUDSTACK-7954:
Assignee: Min Chen
ListTags API is ignoring the resourceID and displaying all the tags of all
resources
Key: CLOUDSTACK-7954
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7954
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: 4.2.0
Reporter: Min Chen
Assignee: Min Chen
Fix For: 4.5.0
Steps to reproduce:
Deployed First VM
Created three resource tags on the First VM
On Clicking on the first VM:
{code}
http://localhost:8080/client/api?command=listTagsresponse=jsonsessionkey=lja4Hf9zlnMFiMwNl6L8g1TFpok%3DresourceId=e22ae536-4711-4570-b4fa-834179e6bc1bresourceType=UserVmlistAll=true_=1416009164305
{ listtagsresponse : { count:3 ,tag : [
{key:description,value:puppetdb,resourcetype:UserVm,resourceid:e22ae536-4711-4570-b4fa-834179e6bc1b,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT},
{key:group,value:ops,resourcetype:UserVm,resourceid:e22ae536-4711-4570-b4fa-834179e6bc1b,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT},
{key:owner,value:klaemm,resourcetype:UserVm,resourceid:e22ae536-4711-4570-b4fa-834179e6bc1b,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT}
] } }
{code}
Deployed Second VM
Created two more resource tags on the newly deployed VM
On Clicking on the Second VM:
{code}
http://localhost:8080/client/api?command=listTagsresponse=jsonsessionkey=lja4Hf9zlnMFiMwNl6L8g1TFpok%3DresourceId=3cd7d704-580d-4f5b-8155-684da7237502resourceType=UserVmlistAll=true_=1416009422177
{ listtagsresponse : { count:5 ,tag : [
{key:description,value:puppetdb,resourcetype:UserVm,resourceid:e22ae536-4711-4570-b4fa-834179e6bc1b,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT},
{key:group,value:ops,resourcetype:UserVm,resourceid:e22ae536-4711-4570-b4fa-834179e6bc1b,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT},
{key:owner,value:klaemm,resourcetype:UserVm,resourceid:e22ae536-4711-4570-b4fa-834179e6bc1b,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT},
{key:parrot,value:bird,resourcetype:UserVm,resourceid:3cd7d704-580d-4f5b-8155-684da7237502,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT},
{key:elephant,value:animal,resourcetype:UserVm,resourceid:3cd7d704-580d-4f5b-8155-684da7237502,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT}
] } }
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7954) ListTags API is ignoring the resourceID and displaying all the tags of all resources
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-7954.
--
Resolution: Fixed
Failed in mySQL executing search criteria resource_tag_view.resource_id =
resourceId or resource_tag_view.resource_uuid = resourceId. If resourceId
passed is UUID string, MySQL is trying to take its long prefix to match with
resource_tag_view.resource_id, thus causing the error.
ListTags API is ignoring the resourceID and displaying all the tags of all
resources
Key: CLOUDSTACK-7954
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7954
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: 4.2.0
Reporter: Min Chen
Assignee: Min Chen
Fix For: 4.5.0
Steps to reproduce:
Deployed First VM
Created three resource tags on the First VM
On Clicking on the first VM:
{code}
http://localhost:8080/client/api?command=listTagsresponse=jsonsessionkey=lja4Hf9zlnMFiMwNl6L8g1TFpok%3DresourceId=e22ae536-4711-4570-b4fa-834179e6bc1bresourceType=UserVmlistAll=true_=1416009164305
{ listtagsresponse : { count:3 ,tag : [
{key:description,value:puppetdb,resourcetype:UserVm,resourceid:e22ae536-4711-4570-b4fa-834179e6bc1b,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT},
{key:group,value:ops,resourcetype:UserVm,resourceid:e22ae536-4711-4570-b4fa-834179e6bc1b,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT},
{key:owner,value:klaemm,resourcetype:UserVm,resourceid:e22ae536-4711-4570-b4fa-834179e6bc1b,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT}
] } }
{code}
Deployed Second VM
Created two more resource tags on the newly deployed VM
On Clicking on the Second VM:
{code}
http://localhost:8080/client/api?command=listTagsresponse=jsonsessionkey=lja4Hf9zlnMFiMwNl6L8g1TFpok%3DresourceId=3cd7d704-580d-4f5b-8155-684da7237502resourceType=UserVmlistAll=true_=1416009422177
{ listtagsresponse : { count:5 ,tag : [
{key:description,value:puppetdb,resourcetype:UserVm,resourceid:e22ae536-4711-4570-b4fa-834179e6bc1b,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT},
{key:group,value:ops,resourcetype:UserVm,resourceid:e22ae536-4711-4570-b4fa-834179e6bc1b,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT},
{key:owner,value:klaemm,resourcetype:UserVm,resourceid:e22ae536-4711-4570-b4fa-834179e6bc1b,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT},
{key:parrot,value:bird,resourcetype:UserVm,resourceid:3cd7d704-580d-4f5b-8155-684da7237502,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT},
{key:elephant,value:animal,resourcetype:UserVm,resourceid:3cd7d704-580d-4f5b-8155-684da7237502,account:atoms,domainid:96ce6f7e-142b-11e4-a917-06e27a00073f,domain:ROOT}
] } }
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7700) Volume Snapshot Async Job returns Success for a failed operation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen updated CLOUDSTACK-7700:
-
Description:
Setup :
Single zone , two clusters , one host in each cluster , have cluster wide
storages and one zone wide primary storage
Steps:
1. Install and configure Adv zone with Vmware 5.5.
2. Deploy VM with DATA disk using Zonewide storage tagged offering and ensure
that root and data disk of this VM are placed in ZWPS
3. Stop the VM and Try to create Volume snapshots till it gets failed.
Observation:
1. It failed to create snapshot due to some temporary network issues .
But It is returning success for a failed operation.
2014-10-13 17:39:52,365 DEBUG [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37 ctx-14ac0075) Done executing
VM work job: com.cloud.storage.VmWorkTakeVolumeSnapshot
{volumeId:4,policyId:0,snapshotId:7,quiesceVm:false,userId:2,accountId:3,vmId:3,handlerName:VolumeApiServiceImpl}
2014-10-13 17:39:52,365 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37 ctx-14ac0075) Complete async
job-37, jobStatus: SUCCEEDED, resultCode: 0, result:
rO0ABXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABw
2014-10-13 17:39:52,375 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Done with run of VM work job:
com.cloud.storage.VmWorkTakeVolumeSnapshot for VM 3, job origin: 36
2014-10-13 17:39:52,375 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Done executing
com.cloud.storage.VmWorkTakeVolumeSnapshot for job-37
2014-10-13 17:39:52,392 DEBUG [o.a.c.f.j.i.SyncQueueManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Sync queue (3) is currently
empty
2014-10-13 17:39:52,393 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Remove job-37 from job
monitoring
2014-10-13 17:39:52,395 DEBUG [c.c.a.ApiResponseHelper]
(API-Job-Executor-21:ctx-d9e77f3d job-36 ctx-16075f77) Unable to find info for
image store snapshot with uuid 91fec32b-77f1-42af-909d-acca69772581
2014-10-13 17:39:52,396 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-21:ctx-d9e77f3d job-36 ctx-16075f77) Complete async job-36,
jobStatus: SUCCEEDED, resultCode: 0, result:
org.apache.cloudstack.api.response.SnapshotResponse/snapshot/
{id:91fec32b-77f1-42af-909d-acca69772581,account:cdcuser1,domainid:0dc68c16-49d3-47ef-9ae2-40e043d3fe81,domain:cdc,snapshottype:MANUAL,volumeid:5097706f-97d6-4133-b010-3c803bca66cf,volumename:DATA-3,volumetype:DATADISK,created:2014-10-13T17:39:43+0530,name:cdcuserinst1_DATA-3_20141013120943,intervaltype:MANUAL,state:Error,tags:[],revertable:false}
2014-10-13 17:39:52,417 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-21:ctx-d9e77f3d job-36) Done executing
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-36
was:
Setup :
Single zone , two clusters , one host in each cluster , have cluster wide
storages and one zone wide primary storage
Steps:
1. Install and configure Adv zone with Vmware 5.5 and CCP 4.3.0.1 setup
2. Deploy VM with DATA disk using Zonewide storage tagged offering and ensure
that root and data disk of this VM are placed in ZWPS
3. Stop the VM and Try to create Volume snapshots till it gets failed.
Observation:
1. It failed to create snapshot due to some temporary network issues .
But It is returning success for a failed operation.
2014-10-13 17:39:52,365 DEBUG [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37 ctx-14ac0075) Done executing
VM work job: com.cloud.storage.VmWorkTakeVolumeSnapshot
{volumeId:4,policyId:0,snapshotId:7,quiesceVm:false,userId:2,accountId:3,vmId:3,handlerName:VolumeApiServiceImpl}
2014-10-13 17:39:52,365 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37 ctx-14ac0075) Complete async
job-37, jobStatus: SUCCEEDED, resultCode: 0, result:
rO0ABXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABw
2014-10-13 17:39:52,375 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Done with run of VM work job:
com.cloud.storage.VmWorkTakeVolumeSnapshot for VM 3, job origin: 36
2014-10-13 17:39:52,375 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Done executing
com.cloud.storage.VmWorkTakeVolumeSnapshot for job-37
2014-10-13 17:39:52,392 DEBUG [o.a.c.f.j.i.SyncQueueManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Sync queue (3) is currently
empty
2014-10-13 17:39:52,393 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Remove job-37 from job
monitoring
2014-10-13 17:39:52,395 DEBUG [c.c.a.ApiResponseHelper]
[jira] [Created] (CLOUDSTACK-7884) Cloudstack MS is not responding (happening randomly) after some restart
Min Chen created CLOUDSTACK-7884: Summary: Cloudstack MS is not responding (happening randomly) after some restart Key: CLOUDSTACK-7884 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7884 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 some times after the restarting the MS ,not able to see the web UI login page (i.e not getting the response from MS when we open http://host:8080/client Page) even though MS is up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7884) Cloudstack MS is not responding (happening randomly) after some restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7884. -- Resolution: Fixed Cloudstack MS is not responding (happening randomly) after some restart --- Key: CLOUDSTACK-7884 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7884 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 some times after the restarting the MS ,not able to see the web UI login page (i.e not getting the response from MS when we open http://host:8080/client Page) even though MS is up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7884) Cloudstack MS is not responding (happening randomly) after some restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14206648#comment-14206648 ] Min Chen commented on CLOUDSTACK-7884: -- Problem: - Management server is not responding intermittently after restart. RCA: - The management server was not responding because it was not started fully and was not ready to take any requests. See the comments above for full analysis Fix: --- During Management server startup Lifecycle Handler Manager start all lifecycle handles one by one sequentially in a random order based on RUN LEVELs of the Lifecycle Handler. Id VirtualMachineManager Lifecycle Handler starts before AsyncJobManager lifecycle Handler and if there are any pending jobs to be processed then the main thread will wait till it finishes the scheduled job, but this job will never executed as asyncjob manager lifecycle handler did not start. Changed the RUN LEVEL of AsyncjobManager to make sure it gets initialised before Virtual manager life cycle handler so that there is a queue to finish the scheduled job. Notest to QA: - Make sure there are some pending virtual machine jobs before restart of the management server to test this. Cloudstack MS is not responding (happening randomly) after some restart --- Key: CLOUDSTACK-7884 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7884 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 some times after the restarting the MS ,not able to see the web UI login page (i.e not getting the response from MS when we open http://host:8080/client Page) even though MS is up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7864) CPVM continues to be in STOPPED' state after failure to start because of a management server restart.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-7864.
--
Resolution: Fixed
CPVM continues to be in STOPPED' state after failure to start because of a
management server restart.
--
Key: CLOUDSTACK-7864
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7864
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
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
CPVM continues to be in STOPPED' state after failure to start because of a
management server restart.
Setup:
Advanced zone set up with KVM hosts.
Steps that led to the problem:
As soon as the zone was set up and enabled , management server was restarted.
I see that the CPVM failed to come up because there were no hosts at the time
it was attempting to start.
After this , even manually trying to start the CPVM does not succeed and the
jobs are hanging.
2014-11-04 21:29:02,613 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-1:ctx-5e9c6a9d job-3/job-16) Unable to complete AsyncJobVO
{id:16, userId: 1, accountId: 1, instanceType: null, instanceId: null, cmd:
com.cloud.vm.VmWorkStart, cmdInfo:
rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIACkoABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAABAAEAAXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwcA,
cmdVersion: 0, status: FAILED, processStatus: 0, resultCode: 530, result:
job cancelled because of management server restart or shutdown, initMsid:
235397185403991, completeMsid: null, lastUpdated: null, lastPolled: null,
created: Tue Nov 04 21:28:01 UTC 2014}
, job origin:3
com.cloud.exception.InsufficientServerCapacityException: Unable to create a
deployment for VM[ConsoleProxy|v-1-VM]Scope=interface
com.cloud.dc.DataCenter; id=1
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:932)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5012)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5156)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:101)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:540)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
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:47)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:497)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2014-11-04 21:29:02,620 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-1:ctx-5e9c6a9d job-3/job-16) Complete async job-16,
jobStatus: FAILED, resultCode: 0, result:
[jira] [Created] (CLOUDSTACK-7864) CPVM continues to be in STOPPED' state after failure to start because of a management server restart.
Min Chen created CLOUDSTACK-7864:
Summary: CPVM continues to be in STOPPED' state after failure to
start because of a management server restart.
Key: CLOUDSTACK-7864
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7864
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
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
CPVM continues to be in STOPPED' state after failure to start because of a
management server restart.
Setup:
Advanced zone set up with KVM hosts.
Steps that led to the problem:
As soon as the zone was set up and enabled , management server was restarted.
I see that the CPVM failed to come up because there were no hosts at the time
it was attempting to start.
After this , even manually trying to start the CPVM does not succeed and the
jobs are hanging.
2014-11-04 21:29:02,613 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-1:ctx-5e9c6a9d job-3/job-16) Unable to complete AsyncJobVO
{id:16, userId: 1, accountId: 1, instanceType: null, instanceId: null, cmd:
com.cloud.vm.VmWorkStart, cmdInfo:
rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIACkoABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAABAAEAAXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwcA,
cmdVersion: 0, status: FAILED, processStatus: 0, resultCode: 530, result: job
cancelled because of management server restart or shutdown, initMsid:
235397185403991, completeMsid: null, lastUpdated: null, lastPolled: null,
created: Tue Nov 04 21:28:01 UTC 2014}
, job origin:3
com.cloud.exception.InsufficientServerCapacityException: Unable to create a
deployment for VM[ConsoleProxy|v-1-VM]Scope=interface com.cloud.dc.DataCenter;
id=1
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:932)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5012)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5156)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:101)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:540)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
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:47)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:497)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2014-11-04 21:29:02,620 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-1:ctx-5e9c6a9d job-3/job-16) Complete async job-16,
jobStatus: FAILED, resultCode: 0, result:
[jira] [Updated] (CLOUDSTACK-6851) ResourceTagResponse does not have id field due to which resource level permission cannot be granted to any specific resource
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen updated CLOUDSTACK-6851: - Description: This enhancement is related to IAM feature, specially writing automated IAM marvin testcases. Since IAM is disabled in 4.5.0, mark this bug to fix in future release. Fix Version/s: (was: 4.5.0) Future ResourceTagResponse does not have id field due to which resource level permission cannot be granted to any specific resource -- Key: CLOUDSTACK-6851 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6851 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Namita Chaudhari Assignee: Min Chen Labels: None Fix For: Future This enhancement is related to IAM feature, specially writing automated IAM marvin testcases. Since IAM is disabled in 4.5.0, mark this bug to fix in future release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6851) ResourceTagResponse does not have id field due to which resource level permission cannot be granted to any specific resource
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197304#comment-14197304 ] Min Chen commented on CLOUDSTACK-6851: -- This enhancement is related to IAM feature, specially writing automated IAM marvin testcases. Since IAM is disabled in 4.5.0, mark this bug to fix in future release. ResourceTagResponse does not have id field due to which resource level permission cannot be granted to any specific resource -- Key: CLOUDSTACK-6851 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6851 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Namita Chaudhari Assignee: Min Chen Labels: None Fix For: Future This enhancement is related to IAM feature, specially writing automated IAM marvin testcases. Since IAM is disabled in 4.5.0, mark this bug to fix in future release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7427) Bug in Cloudstack 4.2 Root Admin API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197309#comment-14197309 ] Min Chen commented on CLOUDSTACK-7427: -- This is invalid, accountName and domainId in updateAccountCmd are not necessarily required if the user provided id as parameter. Bug in Cloudstack 4.2 Root Admin API Key: CLOUDSTACK-7427 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7427 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: santhosh Assignee: Min Chen Fix For: 4.6.0 Original Estimate: 0.25h Remaining Estimate: 0.25h There is bug in parameters of updateAccount http://cloudstack.apache.org/docs/api/apidocs-4.2/root_admin/updateAccount.html Fix : accountname and domainid must be true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7427) Bug in Cloudstack 4.2 Root Admin API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7427. -- Resolution: Invalid Bug in Cloudstack 4.2 Root Admin API Key: CLOUDSTACK-7427 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7427 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: santhosh Assignee: Min Chen Fix For: 4.6.0 Original Estimate: 0.25h Remaining Estimate: 0.25h There is bug in parameters of updateAccount http://cloudstack.apache.org/docs/api/apidocs-4.2/root_admin/updateAccount.html Fix : accountname and domainid must be true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7832) MySQL deadlock occurred in resetting job_executing_msid of the completed vm worker job causing job queue stuck.
Min Chen created CLOUDSTACK-7832: Summary: MySQL deadlock occurred in resetting job_executing_msid of the completed vm worker job causing job queue stuck. Key: CLOUDSTACK-7832 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7832 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 This is mainly happening for an vm operation involving two VM work jobs consecutively, for example, destroyVM which involved two steps: stopVM and deleteAllVMSnapshots. In updating job_executing_msid column of the first VM worker job, the second VM worker job has been scheduled to run, then we will see such MySQL deadlock exception happening: 2014-09-17 03:26:40,538 ERROR [o.a.c.f.j.i.AsyncJobManagerImpl] (Work-Job-Executor-164:job-831168/job-831176) Double excep tion com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.PreparedStatement@42c4a7ea: UPDATE async_ job SET async_job.job_executing_msid=null WHERE async_job.id = 831176 Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) Due to this exception, the queue item is not purged for the first vm worker job, then all the following operations for the same VM will get stuck. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7833) VM Async work jobs log Was unable to find lock for the key vm_instance errors at warn
Min Chen created CLOUDSTACK-7833: Summary: VM Async work jobs log Was unable to find lock for the key vm_instance errors at warn Key: CLOUDSTACK-7833 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7833 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 When Deploy VM API is processed by the VM orchestration logic, VM Work jobs are created and put in the async job queue. While processing these jobs, log shows a lot of WARN statements as follows 2014-10-28 08:09:13,633 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-100:ctx-e10c4339 job-464 ctx-4d5301e4) Sync job-726 execution on object VmWorkJobQueue.286 2014-10-28 08:09:13,640 WARN [c.c.u.d.Merovingian2] (API-Job-Executor-100:ctx-e10c4339 job-464 ctx-4d5301e4) Was unable to find lock for the key vm_instance286 and thread id 1581663601 2014-10-28 08:18:32,003 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-100:ctx-e10c4339 job-464 ctx-4d5301e4) Sync job-1332 execution on object VmWorkJobQueue.286 2014-10-28 08:18:32,006 WARN [c.c.u.d.Merovingian2] (API-Job-Executor-100:ctx-e10c4339 job-464 ctx-4d5301e4) Was unable to find lock for the key vm_instance286 and thread id 1581663601 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7833) VM Async work jobs log Was unable to find lock for the key vm_instance errors at warn
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7833. -- Resolution: Fixed VM Async work jobs log Was unable to find lock for the key vm_instance errors at warn --- Key: CLOUDSTACK-7833 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7833 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 When Deploy VM API is processed by the VM orchestration logic, VM Work jobs are created and put in the async job queue. While processing these jobs, log shows a lot of WARN statements as follows 2014-10-28 08:09:13,633 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-100:ctx-e10c4339 job-464 ctx-4d5301e4) Sync job-726 execution on object VmWorkJobQueue.286 2014-10-28 08:09:13,640 WARN [c.c.u.d.Merovingian2] (API-Job-Executor-100:ctx-e10c4339 job-464 ctx-4d5301e4) Was unable to find lock for the key vm_instance286 and thread id 1581663601 2014-10-28 08:18:32,003 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-100:ctx-e10c4339 job-464 ctx-4d5301e4) Sync job-1332 execution on object VmWorkJobQueue.286 2014-10-28 08:18:32,006 WARN [c.c.u.d.Merovingian2] (API-Job-Executor-100:ctx-e10c4339 job-464 ctx-4d5301e4) Was unable to find lock for the key vm_instance286 and thread id 1581663601 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7832) MySQL deadlock occurred in resetting job_executing_msid of the completed vm worker job causing job queue stuck.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7832. -- Resolution: Fixed MySQL deadlock occurred in resetting job_executing_msid of the completed vm worker job causing job queue stuck. --- Key: CLOUDSTACK-7832 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7832 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 This is mainly happening for an vm operation involving two VM work jobs consecutively, for example, destroyVM which involved two steps: stopVM and deleteAllVMSnapshots. In updating job_executing_msid column of the first VM worker job, the second VM worker job has been scheduled to run, then we will see such MySQL deadlock exception happening: 2014-09-17 03:26:40,538 ERROR [o.a.c.f.j.i.AsyncJobManagerImpl] (Work-Job-Executor-164:job-831168/job-831176) Double excep tion com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.PreparedStatement@42c4a7ea: UPDATE async_ job SET async_job.job_executing_msid=null WHERE async_job.id = 831176 Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) Due to this exception, the queue item is not purged for the first vm worker job, then all the following operations for the same VM will get stuck. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6587) Domain state cannot be simply changed to Active in case of failure in deleting a domain.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen updated CLOUDSTACK-6587: - Fix Version/s: (was: 4.5.0) Future Domain state cannot be simply changed to Active in case of failure in deleting a domain. Key: CLOUDSTACK-6587 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6587 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Min Chen Priority: Critical Fix For: Future There is a design issue in current deleting domain flow: first, the domain will be marked as inactive, when a domain failed in deletion for various reasons (for example, failed in cleanup a subdomain), in the end, we will change its state back to active. This is incorrect, since during domain deletion, some physical resources are already deleted (like network), which cannot be rolled back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6588) Delete account should go through state transition, not just simply marked as removed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190453#comment-14190453 ] Min Chen commented on CLOUDSTACK-6588: -- This requires design change, update to fix for future release. Delete account should go through state transition, not just simply marked as removed Key: CLOUDSTACK-6588 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6588 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Min Chen Priority: Critical Fix For: 4.5.0 There is a design flaw in deleting account flow. When we delete an account, if there are some failure in the process, we have marked the account as removed (removed column is set), and set cleanup_needed column to true. But account state is not changed, still enabled. This will cause problem. From UI listAccounts, this account will not show up, admin cannot do anything about this account to be cleaned up. Correct way to handle this is to set this account as Inactive, and Removed column is only set when we successfully removed the account. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6587) Domain state cannot be simply changed to Active in case of failure in deleting a domain.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190450#comment-14190450 ] Min Chen commented on CLOUDSTACK-6587: -- This will require design change, will mark it for future release then. Domain state cannot be simply changed to Active in case of failure in deleting a domain. Key: CLOUDSTACK-6587 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6587 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Min Chen Priority: Critical Fix For: 4.5.0 There is a design issue in current deleting domain flow: first, the domain will be marked as inactive, when a domain failed in deletion for various reasons (for example, failed in cleanup a subdomain), in the end, we will change its state back to active. This is incorrect, since during domain deletion, some physical resources are already deleted (like network), which cannot be rolled back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7798) listing 2 guest networks is taking close to 4 seconds (Slow compare to previous releases)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7798. -- Resolution: Fixed Added requestHasSensitiveInfo and responseHasSensitiveInfo annotation to some missing Admin API command classes. listing 2 guest networks is taking close to 4 seconds (Slow compare to previous releases) - Key: CLOUDSTACK-7798 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7798 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Steps: 1. Install and configure Adv zone with XS 6.5 2. Created two guest networks 3. Tried to deploy VM. Observation: While deploying the VM it has to select the network so listnetworks is called from UI. It took close to 4 seconds to list two guest networks. UI dash board is blank for 4 mins -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7797) listSupportedNetworkServices API takes more than 1 second to complete, slow compared to previous 4.3 release
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7797. -- Resolution: Fixed Fixed by removing filtering sensitive information from audit log if command response does not have sensitive information. listSupportedNetworkServices API takes more than 1 second to complete, slow compared to previous 4.3 release Key: CLOUDSTACK-7797 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7797 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 add network offering UI displays Add network offering dialog with only Cancel OK button without wizard content. select OK UI displays error Status dialog with error: Unable to execute API command createnetworkoffering due to missing parameter name select close add network offering frame is then correctly displayed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7778) Start VM checkWorkItem loop should also check VM DB state before going into idle waiting to exit faster.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7778. -- Resolution: Fixed Start VM checkWorkItem loop should also check VM DB state before going into idle waiting to exit faster. Key: CLOUDSTACK-7778 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7778 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.0.0 Reporter: Min Chen Assignee: Min Chen Fix For: 4.5.0 During VM deployment, it may involve starting VR. In the meantime, our HA process may also try to start the same VR for example due to host disconnect. Pre-4.3 release, we didn't serialize these two VR start operations, and tried to use VM state transition failure to tell if there is another concurrent operation. In case of concurrent operation, we are not fail the VM deployment job immediately. Instead, we have retry logic to keep checking op_it_work table to see if some other outstanding items have been working on the same VR. If there is any issue with some dangling op_it_work item, this retry will take more than one hour and then fail even though VR may have already been started a while back by HA process. Although due to recent VMsync framework change, this concurrent VM operations become less, it is still better to check current VM state in the while loop of check op_it_work items to get early exit instead of purely relying on op_it_work table being updated properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7797) listSupportedNetworkServices API takes more than 1 second to complete, slow compared to previous 4.3 release
Min Chen created CLOUDSTACK-7797: Summary: listSupportedNetworkServices API takes more than 1 second to complete, slow compared to previous 4.3 release Key: CLOUDSTACK-7797 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7797 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 add network offering UI displays Add network offering dialog with only Cancel OK button without wizard content. select OK UI displays error Status dialog with error: Unable to execute API command createnetworkoffering due to missing parameter name select close add network offering frame is then correctly displayed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7798) listing 2 guest networks is taking close to 4 seconds (Slow compare to previous releases)
Min Chen created CLOUDSTACK-7798: Summary: listing 2 guest networks is taking close to 4 seconds (Slow compare to previous releases) Key: CLOUDSTACK-7798 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7798 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Steps: 1. Install and configure Adv zone with XS 6.5 2. Created two guest networks 3. Tried to deploy VM. Observation: While deploying the VM it has to select the network so listnetworks is called from UI. It took close to 4 seconds to list two guest networks. UI dash board is blank for 4 mins -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7778) Start VM checkWorkItem loop should also check VM DB state before going into idle waiting to exit faster.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-7778: Assignee: Min Chen Start VM checkWorkItem loop should also check VM DB state before going into idle waiting to exit faster. Key: CLOUDSTACK-7778 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7778 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.0.0 Reporter: Min Chen Assignee: Min Chen Fix For: 4.5.0 During VM deployment, it may involve starting VR. In the meantime, our HA process may also try to start the same VR for example due to host disconnect. Pre-4.3 release, we didn't serialize these two VR start operations, and tried to use VM state transition failure to tell if there is another concurrent operation. In case of concurrent operation, we are not fail the VM deployment job immediately. Instead, we have retry logic to keep checking op_it_work table to see if some other outstanding items have been working on the same VR. If there is any issue with some dangling op_it_work item, this retry will take more than one hour and then fail even though VR may have already been started a while back by HA process. Although due to recent VMsync framework change, this concurrent VM operations become less, it is still better to check current VM state in the while loop of check op_it_work items to get early exit instead of purely relying on op_it_work table being updated properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7778) Start VM checkWorkItem loop should also check VM DB state before going into idle waiting to exit faster.
Min Chen created CLOUDSTACK-7778: Summary: Start VM checkWorkItem loop should also check VM DB state before going into idle waiting to exit faster. Key: CLOUDSTACK-7778 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7778 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.0.0 Reporter: Min Chen Fix For: 4.5.0 During VM deployment, it may involve starting VR. In the meantime, our HA process may also try to start the same VR for example due to host disconnect. Pre-4.3 release, we didn't serialize these two VR start operations, and tried to use VM state transition failure to tell if there is another concurrent operation. In case of concurrent operation, we are not fail the VM deployment job immediately. Instead, we have retry logic to keep checking op_it_work table to see if some other outstanding items have been working on the same VR. If there is any issue with some dangling op_it_work item, this retry will take more than one hour and then fail even though VR may have already been started a while back by HA process. Although due to recent VMsync framework change, this concurrent VM operations become less, it is still better to check current VM state in the while loop of check op_it_work items to get early exit instead of purely relying on op_it_work table being updated properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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
[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
[jira] [Created] (CLOUDSTACK-7700) Volume Snapshot Async Job returns Success for a failed operation
Min Chen created CLOUDSTACK-7700:
Summary: Volume Snapshot Async Job returns Success for a failed
operation
Key: CLOUDSTACK-7700
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7700
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Storage Controller
Affects Versions: 4.3.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
Setup :
Single zone , two clusters , one host in each cluster , have cluster wide
storages and one zone wide primary storage
Steps:
1. Install and configure Adv zone with Vmware 5.5 and CCP 4.3.0.1 IDCF branch
setup
2. Deploy VM with DATA disk using Zonewide storage tagged offering and ensure
that root and data disk of this VM are placed in ZWPS
3. Stop the VM and Try to create Volume snapshots till it gets failed.
Observation:
1. It failed to create snapshot due to some temporary network issues .
But It is returning success for a failed operation.
2014-10-13 17:39:52,365 DEBUG [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37 ctx-14ac0075) Done executing
VM work job: com.cloud.storage.VmWorkTakeVolumeSnapshot
{volumeId:4,policyId:0,snapshotId:7,quiesceVm:false,userId:2,accountId:3,vmId:3,handlerName:VolumeApiServiceImpl}
2014-10-13 17:39:52,365 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37 ctx-14ac0075) Complete async
job-37, jobStatus: SUCCEEDED, resultCode: 0, result:
rO0ABXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABw
2014-10-13 17:39:52,375 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Done with run of VM work job:
com.cloud.storage.VmWorkTakeVolumeSnapshot for VM 3, job origin: 36
2014-10-13 17:39:52,375 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Done executing
com.cloud.storage.VmWorkTakeVolumeSnapshot for job-37
2014-10-13 17:39:52,392 DEBUG [o.a.c.f.j.i.SyncQueueManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Sync queue (3) is currently
empty
2014-10-13 17:39:52,393 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Remove job-37 from job
monitoring
2014-10-13 17:39:52,395 DEBUG [c.c.a.ApiResponseHelper]
(API-Job-Executor-21:ctx-d9e77f3d job-36 ctx-16075f77) Unable to find info for
image store snapshot with uuid 91fec32b-77f1-42af-909d-acca69772581
2014-10-13 17:39:52,396 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-21:ctx-d9e77f3d job-36 ctx-16075f77) Complete async job-36,
jobStatus: SUCCEEDED, resultCode: 0, result:
org.apache.cloudstack.api.response.SnapshotResponse/snapshot/
{id:91fec32b-77f1-42af-909d-acca69772581,account:cdcuser1,domainid:0dc68c16-49d3-47ef-9ae2-40e043d3fe81,domain:cdc,snapshottype:MANUAL,volumeid:5097706f-97d6-4133-b010-3c803bca66cf,volumename:DATA-3,volumetype:DATADISK,created:2014-10-13T17:39:43+0530,name:cdcuserinst1_DATA-3_20141013120943,intervaltype:MANUAL,state:Error,tags:[],revertable:false}
2014-10-13 17:39:52,417 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-21:ctx-d9e77f3d job-36) Done executing
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-36
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7628) VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run.
Min Chen created CLOUDSTACK-7628: Summary: VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run. Key: CLOUDSTACK-7628 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7628 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 Priority: Critical Fix For: 4.5.0 Based on design, when VM worker job cleanup thread runs, it should only expunge those vm work jobs that are completed more than one hour ago. This is to prevent some Db constraint error in expunging these jobs since there are still reference to the worker job in async_job_map table. Also on some racing condition, we will encounter NPE due to removal of such jobs too quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7628) VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-7628: Assignee: Min Chen VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run. --- Key: CLOUDSTACK-7628 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7628 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 Based on design, when VM worker job cleanup thread runs, it should only expunge those vm work jobs that are completed more than one hour ago. This is to prevent some Db constraint error in expunging these jobs since there are still reference to the worker job in async_job_map table. Also on some racing condition, we will encounter NPE due to removal of such jobs too quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7628) VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14147178#comment-14147178 ] Min Chen commented on CLOUDSTACK-7628: -- This is caused by a bug in code to set search criteria bind value, mismatched with the bind parameter defined earlier, thus cut date criteria is not used. VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run. --- Key: CLOUDSTACK-7628 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7628 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 Based on design, when VM worker job cleanup thread runs, it should only expunge those vm work jobs that are completed more than one hour ago. This is to prevent some Db constraint error in expunging these jobs since there are still reference to the worker job in async_job_map table. Also on some racing condition, we will encounter NPE due to removal of such jobs too quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7628) VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7628. -- Resolution: Fixed VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run. --- Key: CLOUDSTACK-7628 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7628 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 Based on design, when VM worker job cleanup thread runs, it should only expunge those vm work jobs that are completed more than one hour ago. This is to prevent some Db constraint error in expunging these jobs since there are still reference to the worker job in async_job_map table. Also on some racing condition, we will encounter NPE due to removal of such jobs too quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7589) VM not Starting and always stuck in Stopped state after management server restarts
Min Chen created CLOUDSTACK-7589: Summary: VM not Starting and always stuck in Stopped state after management server restarts Key: CLOUDSTACK-7589 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7589 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 Priority: Blocker Fix For: 4.5.0 When a VM job is executing but not finished, if we shutdown and restart management server, all the future VM jobs will get stuck in Stopped state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7589) VM not Starting and always stuck in Stopped state after management server restarts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-7589: Assignee: Min Chen VM not Starting and always stuck in Stopped state after management server restarts -- Key: CLOUDSTACK-7589 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7589 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: Blocker Fix For: 4.5.0 When a VM job is executing but not finished, if we shutdown and restart management server, all the future VM jobs will get stuck in Stopped state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7589) VM not Starting and always stuck in Stopped state after management server restarts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7589. -- Resolution: Fixed VM not Starting and always stuck in Stopped state after management server restarts -- Key: CLOUDSTACK-7589 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7589 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: Blocker Fix For: 4.5.0 When a VM job is executing but not finished, if we shutdown and restart management server, all the future VM jobs will get stuck in Stopped state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7589) VM not Starting and always stuck in Stopped state after management server restarts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14141433#comment-14141433 ] Min Chen commented on CLOUDSTACK-7589: -- The cleanup logic in management server restart caused Db exception, and thus cause db cleanup failure. VM not Starting and always stuck in Stopped state after management server restarts -- Key: CLOUDSTACK-7589 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7589 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: Blocker Fix For: 4.5.0 When a VM job is executing but not finished, if we shutdown and restart management server, all the future VM jobs will get stuck in Stopped state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7589) VM not Starting and always stuck in Stopped state after management server restarts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14141433#comment-14141433 ] Min Chen edited comment on CLOUDSTACK-7589 at 9/19/14 10:24 PM: The cleanup logic in management server restart caused Db exception, and thus cause db cleanup failure, and thus leaving some left over jobs hanging around, and block future VM operations. was (Author: minchen07): The cleanup logic in management server restart caused Db exception, and thus cause db cleanup failure. VM not Starting and always stuck in Stopped state after management server restarts -- Key: CLOUDSTACK-7589 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7589 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: Blocker Fix For: 4.5.0 When a VM job is executing but not finished, if we shutdown and restart management server, all the future VM jobs will get stuck in Stopped state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7563) ClassCastException in VirtualMachineManagerImpl in handling various Agent command answer.
Min Chen created CLOUDSTACK-7563: Summary: ClassCastException in VirtualMachineManagerImpl in handling various Agent command answer. Key: CLOUDSTACK-7563 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7563 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 irtualMachineManagerImpl has many methods directly cast the Answer received from AgentManager.send or AgentManager.easySend to the expected Answer class in the normal case. This will throw unhandled ClassCastException in some unexcepted cases where host is down and agent is disconnected, which will lead to cloud instability. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7563) ClassCastException in VirtualMachineManagerImpl in handling various Agent command answer.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7563. -- Resolution: Fixed Changed VirtualMachineManagerImpl to use check Answer cast to avoid potential unhandled exception. ClassCastException in VirtualMachineManagerImpl in handling various Agent command answer. - Key: CLOUDSTACK-7563 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7563 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 irtualMachineManagerImpl has many methods directly cast the Answer received from AgentManager.send or AgentManager.easySend to the expected Answer class in the normal case. This will throw unhandled ClassCastException in some unexcepted cases where host is down and agent is disconnected, which will lead to cloud instability. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7566) Many jobs getting stuck in pending state and cloud is unusable
Min Chen created CLOUDSTACK-7566: Summary: Many jobs getting stuck in pending state and cloud is unusable Key: CLOUDSTACK-7566 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7566 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 Priority: Blocker Fix For: 4.5.0 Many jobs are getting stuck with errors like: 2014-09-09 18:55:41,964 WARN [jobs.impl.AsyncJobMonitor] (Timer-1:ctx-1e7a8a7e) Task (job-355415) has been pending for 690 seconds Even jobs that apparently succeed are getting the same error. Async job table is not updated with complete even though job is completed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7566) Many jobs getting stuck in pending state and cloud is unusable
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-7566: Assignee: Min Chen Many jobs getting stuck in pending state and cloud is unusable -- Key: CLOUDSTACK-7566 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7566 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: Blocker Fix For: 4.5.0 Many jobs are getting stuck with errors like: 2014-09-09 18:55:41,964 WARN [jobs.impl.AsyncJobMonitor] (Timer-1:ctx-1e7a8a7e) Task (job-355415) has been pending for 690 seconds Even jobs that apparently succeed are getting the same error. Async job table is not updated with complete even though job is completed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7566) Many jobs getting stuck in pending state and cloud is unusable
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7566. -- Resolution: Fixed Many jobs getting stuck in pending state and cloud is unusable -- Key: CLOUDSTACK-7566 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7566 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: Blocker Fix For: 4.5.0 Many jobs are getting stuck with errors like: 2014-09-09 18:55:41,964 WARN [jobs.impl.AsyncJobMonitor] (Timer-1:ctx-1e7a8a7e) Task (job-355415) has been pending for 690 seconds Even jobs that apparently succeed are getting the same error. Async job table is not updated with complete even though job is completed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7566) Many jobs getting stuck in pending state and cloud is unusable
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136380#comment-14136380 ] Min Chen commented on CLOUDSTACK-7566: -- Guard all potential unhandled exception in MessageBus gate.enter and gate.leave routine to avoid potential lock holdup. Since each API will invoke messageBus to publish event, any potential lock holdup will make jobs pending in the system and render cloud unusable. Many jobs getting stuck in pending state and cloud is unusable -- Key: CLOUDSTACK-7566 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7566 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 Priority: Blocker Fix For: 4.5.0 Many jobs are getting stuck with errors like: 2014-09-09 18:55:41,964 WARN [jobs.impl.AsyncJobMonitor] (Timer-1:ctx-1e7a8a7e) Task (job-355415) has been pending for 690 seconds Even jobs that apparently succeed are getting the same error. Async job table is not updated with complete even though job is completed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7553) Channel Closed error after SSVM and CPVM agents reconnect back to clustered management server after host is disconnected.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-7553: Assignee: Min Chen Channel Closed error after SSVM and CPVM agents reconnect back to clustered management server after host is disconnected. - Key: CLOUDSTACK-7553 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7553 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 1. Set up a clustered management server setup using Vmware. Note down the MS id that SSVM agent is connected to from DB host table. 2. Disable uplink on hypervisor host that runs SSVM. Now in the log we should see Channel is closed error, which is correct and as expected. 3. Waited for some time, enable uplink back on hypervisor, SSVM agent will reconnect back to MS. Make sure that SSVM agent is connected to a different MS node from the one we noted down in step #1. If not, try #2 and #3 again until that happens. 4. Now we will continue seeing Channel is closed error from the MS log noted down in step #1, this is not correct. Command sent to SSVM will fail if the command is sent from MS node noted down in step #1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7553) Channel Closed error after SSVM and CPVM agents reconnect back to clustered management server after host is disconnected.
Min Chen created CLOUDSTACK-7553: Summary: Channel Closed error after SSVM and CPVM agents reconnect back to clustered management server after host is disconnected. Key: CLOUDSTACK-7553 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7553 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Min Chen Priority: Critical Fix For: 4.5.0 1. Set up a clustered management server setup using Vmware. Note down the MS id that SSVM agent is connected to from DB host table. 2. Disable uplink on hypervisor host that runs SSVM. Now in the log we should see Channel is closed error, which is correct and as expected. 3. Waited for some time, enable uplink back on hypervisor, SSVM agent will reconnect back to MS. Make sure that SSVM agent is connected to a different MS node from the one we noted down in step #1. If not, try #2 and #3 again until that happens. 4. Now we will continue seeing Channel is closed error from the MS log noted down in step #1, this is not correct. Command sent to SSVM will fail if the command is sent from MS node noted down in step #1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7553) Channel Closed error after SSVM and CPVM agents reconnect back to clustered management server after host is disconnected.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7553. -- Resolution: Fixed Please follow reproducible steps mentioned in the bug description to verify this fix. Channel Closed error after SSVM and CPVM agents reconnect back to clustered management server after host is disconnected. - Key: CLOUDSTACK-7553 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7553 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 1. Set up a clustered management server setup using Vmware. Note down the MS id that SSVM agent is connected to from DB host table. 2. Disable uplink on hypervisor host that runs SSVM. Now in the log we should see Channel is closed error, which is correct and as expected. 3. Waited for some time, enable uplink back on hypervisor, SSVM agent will reconnect back to MS. Make sure that SSVM agent is connected to a different MS node from the one we noted down in step #1. If not, try #2 and #3 again until that happens. 4. Now we will continue seeing Channel is closed error from the MS log noted down in step #1, this is not correct. Command sent to SSVM will fail if the command is sent from MS node noted down in step #1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7542) CreateNetworkCmd and CreateNetworkCmdByAdmin both have their own vlan parameters
Min Chen created CLOUDSTACK-7542: Summary: CreateNetworkCmd and CreateNetworkCmdByAdmin both have their own vlan parameters Key: CLOUDSTACK-7542 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7542 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Fix For: 4.5.0 vlan parameter appears in both CreateNetworkCmd and CreateNetworkCmdByAdmin, but this parameter should only be specified by ROOT_ADMIN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7542) CreateNetworkCmd and CreateNetworkCmdByAdmin both have their own vlan parameters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7542. -- Resolution: Fixed CreateNetworkCmd and CreateNetworkCmdByAdmin both have their own vlan parameters -- Key: CLOUDSTACK-7542 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7542 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Fix For: 4.5.0 vlan parameter appears in both CreateNetworkCmd and CreateNetworkCmdByAdmin, but this parameter should only be specified by ROOT_ADMIN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7542) CreateNetworkCmd and CreateNetworkCmdByAdmin both have their own vlan parameters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14132293#comment-14132293 ] Min Chen commented on CLOUDSTACK-7542: -- Remove vlan parameter from CreateNetworkCmd, so that this parameter can only be provided by ROOT_ADMIN. For user, it will be ignored. CreateNetworkCmd and CreateNetworkCmdByAdmin both have their own vlan parameters -- Key: CLOUDSTACK-7542 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7542 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Fix For: 4.5.0 vlan parameter appears in both CreateNetworkCmd and CreateNetworkCmdByAdmin, but this parameter should only be specified by ROOT_ADMIN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7471) Regular user is allowed to deleteNetwork/RestartNetwork that does not belong to him.He is also able to deploy Vm for other users.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14119337#comment-14119337
]
Min Chen commented on CLOUDSTACK-7471:
--
This bug is caused by incorrect merge resolution in cherry-picking the commit
of disabling IAM feature from 4.4 to master branch.
Sangeetha has written marvin automated testcases for these bugs, can simply
verify the fix by running those automated tests.
Regular user is allowed to deleteNetwork/RestartNetwork that does not belong
to him.He is also able to deploy Vm for other users.
-
Key: CLOUDSTACK-7471
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7471
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: Min Chen
Scenario 1 :
Regular user is allowed to delete networks that belong to other users
Create a regular user - d1-a in Domain - d1.
Create another regular user - d1-b in Domain - d1.
As user d1-a , create a network.
As user d1-b , delete network that belongs to d1-a.
We expect this to not succeed.
But we are allowed to do this.
Snippet from apilog indicating AccountId- 92 is attempting the restart
network.
2014-08-29 06:59:57,912 INFO [a.c.c.a.ApiServer]
(catalina-exec-23:ctx-05f928b8 ctx-c081eb69) (userId=92 accountId=92
sessionId=DC
A599AA77169CA107BA0AADA19667F7) 10.215.3.6 – GET
command=deleteNetworkid=2f2cc737-ba0f-4806-a81b-92a5749cfe7bresponse=jsonsessi
onkey=NHvM0k5Rg%2FQspJg2g0YnQP%2Fhq34%3D 200 { deletenetworkresponse :
{jobid:05daf212-1aa7-4885-b133-2645a6ceb7df}
}
Snippet from DB indicating that the owner of network is account_id=89 .
mysql select account_id,domain_id from networks where
uuid=2f2cc737-ba0f-4806-a81b-92a5749cfe7b;
-+
account_iddomain_id
-+
8937
-+
1 row in set (0.00 sec)
Snippet from management server logs indicating success:
2014-08-29 06:59:57,911 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-23:ctx-05f928b8 ctx-c081eb69) submit async job-995,
details: AsyncJobVO {id:995, userId: 92, accountId: 92, instanceType: None,
instanceId: null, cmd: org.apache.cloudstack.api.comman
d.user.network.DeleteNetworkCmd, cmdInfo:
{response:json,id:2f2cc737-ba0f-4806-a81b-92a5749cfe7b,sessionkey:NHvM0k5Rg/Qs
pJg2g0YnQP/hq34\u003d,ctxDetails:
{\com.cloud.network.Network\:\2f2cc737-ba0f-4806-a81b-92a5749cfe7b\}
,cmdEventType:NETW
ORK.DELETE,ctxUserId:92,httpmethod:GET,uuid:2f2cc737-ba0f-4806-a81b-92a5749cfe7b,ctxAccountId:92,ctxStartEventId
:3020}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode:
0, result: null, initMsid: 82324189320212, completeMsid
: null, lastUpdated: null, lastPolled: null, created: null}
2014-08-29 06:59:57,912 DEBUG [c.c.a.ApiServlet]
(catalina-exec-23:ctx-05f928b8 ctx-c081eb69) ===END=== 10.215.3.6 – GET
command
=deleteNetworkid=2f2cc737-ba0f-4806-a81b-92a5749cfe7bresponse=jsonsessionkey=NHvM0k5Rg%2FQspJg2g0YnQP%2Fhq34%3D
2014-08-29 06:59:57,934 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Network is al
ready shutdown: Ntwk[390|Guest|8]
2014-08-29 06:59:57,937 DEBUG [c.c.n.r.RulesManagerImpl]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Releasing 0 port f
orwarding rules for network id=390
2014-08-29 06:59:57,938 DEBUG [c.c.n.r.RulesManagerImpl]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Releasing 0 static
nat rules for network id=390
2014-08-29 06:59:57,939 DEBUG [c.c.n.r.RulesManagerImpl]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) There are no port
forwarding rules to apply for network id=390
2014-08-29 06:59:57,940 DEBUG [c.c.n.r.RulesManagerImpl]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) There are no stati
c nat rules to apply for network id=390
2014-08-29 06:59:57,941 DEBUG [c.c.n.r.RulesManagerImpl]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully relea
sed rules for network id=390 and # of rules now = 0
2014-08-29 06:59:57,941 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully
cleaned up portForwarding/staticNat rules for network id=390
2014-08-29 06:59:57,942 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Found
0 lb rules to cleanup
2014-08-29 06:59:57,942 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully
[jira] [Resolved] (CLOUDSTACK-7471) Regular user is allowed to deleteNetwork/RestartNetwork that does not belong to him.He is also able to deploy Vm for other users.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-7471.
--
Resolution: Fixed
Regular user is allowed to deleteNetwork/RestartNetwork that does not belong
to him.He is also able to deploy Vm for other users.
-
Key: CLOUDSTACK-7471
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7471
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: Min Chen
Scenario 1 :
Regular user is allowed to delete networks that belong to other users
Create a regular user - d1-a in Domain - d1.
Create another regular user - d1-b in Domain - d1.
As user d1-a , create a network.
As user d1-b , delete network that belongs to d1-a.
We expect this to not succeed.
But we are allowed to do this.
Snippet from apilog indicating AccountId- 92 is attempting the restart
network.
2014-08-29 06:59:57,912 INFO [a.c.c.a.ApiServer]
(catalina-exec-23:ctx-05f928b8 ctx-c081eb69) (userId=92 accountId=92
sessionId=DC
A599AA77169CA107BA0AADA19667F7) 10.215.3.6 – GET
command=deleteNetworkid=2f2cc737-ba0f-4806-a81b-92a5749cfe7bresponse=jsonsessi
onkey=NHvM0k5Rg%2FQspJg2g0YnQP%2Fhq34%3D 200 { deletenetworkresponse :
{jobid:05daf212-1aa7-4885-b133-2645a6ceb7df}
}
Snippet from DB indicating that the owner of network is account_id=89 .
mysql select account_id,domain_id from networks where
uuid=2f2cc737-ba0f-4806-a81b-92a5749cfe7b;
-+
account_iddomain_id
-+
8937
-+
1 row in set (0.00 sec)
Snippet from management server logs indicating success:
2014-08-29 06:59:57,911 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-23:ctx-05f928b8 ctx-c081eb69) submit async job-995,
details: AsyncJobVO {id:995, userId: 92, accountId: 92, instanceType: None,
instanceId: null, cmd: org.apache.cloudstack.api.comman
d.user.network.DeleteNetworkCmd, cmdInfo:
{response:json,id:2f2cc737-ba0f-4806-a81b-92a5749cfe7b,sessionkey:NHvM0k5Rg/Qs
pJg2g0YnQP/hq34\u003d,ctxDetails:
{\com.cloud.network.Network\:\2f2cc737-ba0f-4806-a81b-92a5749cfe7b\}
,cmdEventType:NETW
ORK.DELETE,ctxUserId:92,httpmethod:GET,uuid:2f2cc737-ba0f-4806-a81b-92a5749cfe7b,ctxAccountId:92,ctxStartEventId
:3020}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode:
0, result: null, initMsid: 82324189320212, completeMsid
: null, lastUpdated: null, lastPolled: null, created: null}
2014-08-29 06:59:57,912 DEBUG [c.c.a.ApiServlet]
(catalina-exec-23:ctx-05f928b8 ctx-c081eb69) ===END=== 10.215.3.6 – GET
command
=deleteNetworkid=2f2cc737-ba0f-4806-a81b-92a5749cfe7bresponse=jsonsessionkey=NHvM0k5Rg%2FQspJg2g0YnQP%2Fhq34%3D
2014-08-29 06:59:57,934 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Network is al
ready shutdown: Ntwk[390|Guest|8]
2014-08-29 06:59:57,937 DEBUG [c.c.n.r.RulesManagerImpl]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Releasing 0 port f
orwarding rules for network id=390
2014-08-29 06:59:57,938 DEBUG [c.c.n.r.RulesManagerImpl]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Releasing 0 static
nat rules for network id=390
2014-08-29 06:59:57,939 DEBUG [c.c.n.r.RulesManagerImpl]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) There are no port
forwarding rules to apply for network id=390
2014-08-29 06:59:57,940 DEBUG [c.c.n.r.RulesManagerImpl]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) There are no stati
c nat rules to apply for network id=390
2014-08-29 06:59:57,941 DEBUG [c.c.n.r.RulesManagerImpl]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully relea
sed rules for network id=390 and # of rules now = 0
2014-08-29 06:59:57,941 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully
cleaned up portForwarding/staticNat rules for network id=390
2014-08-29 06:59:57,942 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Found
0 lb rules to cleanup
2014-08-29 06:59:57,942 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Successfully
cleaned up load balancing rules for network id=390
2014-08-29 06:59:57,949 DEBUG [c.c.n.f.FirewallManagerImpl]
(API-Job-Executor-40:ctx-71036d41 job-995 ctx-502dafa1) Releasing 0 firewall
rules for network id=390
2014-08-29 06:59:57,950 DEBUG [c.c.n.f.FirewallManagerImpl]
[jira] [Resolved] (CLOUDSTACK-7266) Deleting account is not cleaning the snapshot entries in secondary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7266. -- Resolution: Fixed Deleting account is not cleaning the snapshot entries in secondary storage -- Key: CLOUDSTACK-7266 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7266 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.5.0 Reporter: manasaveloori Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Attachments: cloud.log-20140806.gz, management-server.rar, mysqldump45.dmp Steps: 1. Deployed CS with ESXi5.1 2. Created VM with data disk. 3. Created snapshots on both root and data disks. 4. Now deleted the account. id: 4 account_name: test uuid: c55b8251-7bb0-4531-bd7e-7811d55160e6 type: 0 domain_id: 1 state: enabled removed: 2014-08-06 06:04:50 cleanup_needed: 0 network_domain: NULL default_zone_id: NULL default: 0 5. All the snapshots got deleted as apart of account clean up in DB mysql select * from snapshots where account_id=4\G; *** 1. row *** id: 38 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_2014080605 uuid: 716f0dd5-056e-4cab-b814-125fc6fe84e6 snapshot_type: 0 type_description: MANUAL size: 2147483648 created: 2014-08-06 05:44:44 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 2. row *** id: 39 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_20140806054650 uuid: ea949547-5ef7-40b0-99a6-152d346a0ad6 snapshot_type: 3 type_description: HOURLY size: 2147483648 created: 2014-08-06 05:46:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 3. row *** id: 40 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_20140806055150 uuid: b8af0810-b08a-40bd-a114-13a4d75907ca snapshot_type: 4 type_description: DAILY size: 2147483648 created: 2014-08-06 05:51:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 4. row *** id: 41 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_20140806055150 uuid: dda5cfb7-f5ab-4bd0-bdd3-953932e77f5e snapshot_type: 5 type_description: WEEKLY size: 2147483648 created: 2014-08-06 05:51:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 5. row *** id: 42 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 19 disk_offering_id: 3 status: Destroyed path: NULL name: testvmacct1_DATA-11_20140806055150 uuid: 69c8b7d1-baab-42ac-9a7d-dbdb0688654f snapshot_type: 3 type_description: HOURLY size: 5368709120 created: 2014-08-06 05:51:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 6. row *** id: 44 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 19 disk_offering_id: 3 status:
[jira] [Commented] (CLOUDSTACK-7266) Deleting account is not cleaning the snapshot entries in secondary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14109981#comment-14109981 ] Min Chen commented on CLOUDSTACK-7266: -- Problem: --- After an account is deleted, the snapshot directory (for each volume) created for the account is not deleted on secondary storage. Root Cause Analysis: -- In cleaning up account, MS will send DeleteSnapshotsDirCommand to SSVM, but SSVM failed to execute this command due to the following error: 2014-08-06 06:04:52,773 WARN [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-1:null) Failed to delete file /mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/snapshots/4/19/*, err=rm: cannot remove `/mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/snapshots/4/19/9ef00274-3b42-4e4d-81a2-13e055f7f162': Is a directoryrm: cannot remove `/mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/snapshots/4/19/b3086b0a-d8fb-453f-9339-7b4ff4b12a02': Is a directoryrm: cannot remove `/mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/snapshots/4/19/d73794f8-0ef1-4a06-a800-8ae9ed344742': Is a directory The snapshot directory has nested directory, we should use recursive option for rm command. Proposed Solution: --- We need to rm -r option on SSVM to remove the snapshot directory. QA notes: - Steps to reproduce: 1. Deployed CS with ESXi5.1 2. Create an account demo. 3. Created VM with data disk by logging into CS as demo. 3. Created snapshots on both root and data disks. 4. Now deleted the account demo. Expected result: - On NFS secondary storage, we should see an empty folder under snapshots/account id for demo. Deleting account is not cleaning the snapshot entries in secondary storage -- Key: CLOUDSTACK-7266 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7266 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.5.0 Reporter: manasaveloori Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Attachments: cloud.log-20140806.gz, management-server.rar, mysqldump45.dmp Steps: 1. Deployed CS with ESXi5.1 2. Created VM with data disk. 3. Created snapshots on both root and data disks. 4. Now deleted the account. id: 4 account_name: test uuid: c55b8251-7bb0-4531-bd7e-7811d55160e6 type: 0 domain_id: 1 state: enabled removed: 2014-08-06 06:04:50 cleanup_needed: 0 network_domain: NULL default_zone_id: NULL default: 0 5. All the snapshots got deleted as apart of account clean up in DB mysql select * from snapshots where account_id=4\G; *** 1. row *** id: 38 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_2014080605 uuid: 716f0dd5-056e-4cab-b814-125fc6fe84e6 snapshot_type: 0 type_description: MANUAL size: 2147483648 created: 2014-08-06 05:44:44 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 2. row *** id: 39 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_20140806054650 uuid: ea949547-5ef7-40b0-99a6-152d346a0ad6 snapshot_type: 3 type_description: HOURLY size: 2147483648 created: 2014-08-06 05:46:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 3. row *** id: 40 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_20140806055150 uuid: b8af0810-b08a-40bd-a114-13a4d75907ca snapshot_type: 4 type_description: DAILY size: 2147483648 created: 2014-08-06 05:51:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware
[jira] [Created] (CLOUDSTACK-7394) Caller should be owner after creating template from snapshot/volume
Min Chen created CLOUDSTACK-7394: Summary: Caller should be owner after creating template from snapshot/volume Key: CLOUDSTACK-7394 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7394 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.0.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Caller should be owner of template when creating template from snapshot or template. Currently the owner is set as snapshot or volume owner and they are charged, this is wrong. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7394) Caller should be owner after creating template from snapshot/volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7394. -- Resolution: Fixed The account_id for the template created should be the caller account id, also resource_count table should be properly updated for caller instead of volume/snapshot owner. Caller should be owner after creating template from snapshot/volume --- Key: CLOUDSTACK-7394 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7394 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.0.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Caller should be owner of template when creating template from snapshot or template. Currently the owner is set as snapshot or volume owner and they are charged, this is wrong. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7344) VOLUME.DELETE usage event missing for VM's in ERROR state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7344. -- Resolution: Fixed VOLUME.DELETE usage event missing for VM's in ERROR state - Key: CLOUDSTACK-7344 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7344 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.5.0 CloudStack is not generating the VOLUME.DELETE event for VM's which are failed to be deployed. That is if the VM deployment is failed for some reason. The VM state is updated as ERROR and cleanup is performed to release the resources allocated to the VM. As a part of cleanup volume state is updated as 'DESTROY' but no VOLUME.DELETE event is generated causing the usage issue customer is seeing now. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7344) VOLUME.DELETE usage event missing for VM's in ERROR state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106241#comment-14106241 ] Min Chen commented on CLOUDSTACK-7344: -- When we mark a volume as destroyed (not really expunged), we should always publish VOLUME.DELETE event. VOLUME.DELETE usage event missing for VM's in ERROR state - Key: CLOUDSTACK-7344 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7344 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.5.0 CloudStack is not generating the VOLUME.DELETE event for VM's which are failed to be deployed. That is if the VM deployment is failed for some reason. The VM state is updated as ERROR and cleanup is performed to release the resources allocated to the VM. As a part of cleanup volume state is updated as 'DESTROY' but no VOLUME.DELETE event is generated causing the usage issue customer is seeing now. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7266) Deleting account is not cleaning the snapshot entries in secondary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106256#comment-14106256 ] Min Chen commented on CLOUDSTACK-7266: -- This is the reason indicated from SSVM log: 2014-08-06 06:04:52,773 WARN [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-1:null) Failed to delete file /mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/snapshots/4/19/*, err=rm: cannot remove `/mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/snapshots/4/19/9ef00274-3b42-4e4d-81a2-13e055f7f162': Is a directoryrm: cannot remove `/mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/snapshots/4/19/b3086b0a-d8fb-453f-9339-7b4ff4b12a02': Is a directoryrm: cannot remove `/mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/snapshots/4/19/d73794f8-0ef1-4a06-a800-8ae9ed344742': Is a directory The snapshot directory has nested directory, we should use recursive option for rm command. Deleting account is not cleaning the snapshot entries in secondary storage -- Key: CLOUDSTACK-7266 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7266 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.5.0 Reporter: manasaveloori Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Attachments: cloud.log-20140806.gz, management-server.rar, mysqldump45.dmp Steps: 1. Deployed CS with ESXi5.1 2. Created VM with data disk. 3. Created snapshots on both root and data disks. 4. Now deleted the account. id: 4 account_name: test uuid: c55b8251-7bb0-4531-bd7e-7811d55160e6 type: 0 domain_id: 1 state: enabled removed: 2014-08-06 06:04:50 cleanup_needed: 0 network_domain: NULL default_zone_id: NULL default: 0 5. All the snapshots got deleted as apart of account clean up in DB mysql select * from snapshots where account_id=4\G; *** 1. row *** id: 38 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_2014080605 uuid: 716f0dd5-056e-4cab-b814-125fc6fe84e6 snapshot_type: 0 type_description: MANUAL size: 2147483648 created: 2014-08-06 05:44:44 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 2. row *** id: 39 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_20140806054650 uuid: ea949547-5ef7-40b0-99a6-152d346a0ad6 snapshot_type: 3 type_description: HOURLY size: 2147483648 created: 2014-08-06 05:46:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 3. row *** id: 40 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_20140806055150 uuid: b8af0810-b08a-40bd-a114-13a4d75907ca snapshot_type: 4 type_description: DAILY size: 2147483648 created: 2014-08-06 05:51:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 4. row *** id: 41 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_20140806055150 uuid: dda5cfb7-f5ab-4bd0-bdd3-953932e77f5e snapshot_type: 5 type_description: WEEKLY size: 2147483648 created: 2014-08-06 05:51:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 5. row ***
[jira] [Resolved] (CLOUDSTACK-7328) [Automation] Register ISO failing with invalid iso format error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7328. -- Resolution: Fixed [Automation] Register ISO failing with invalid iso format error - Key: CLOUDSTACK-7328 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7328 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: ISO Affects Versions: 4.5.0 Environment: KVM and Xen Reporter: Rayees Namathponnan Assignee: Min Chen Priority: Blocker Fix For: 4.5.0 Attachments: vmops.log Steps to reproduce 1) Run the BVT test TestISO 2) Test case registering ISO with valid URL, Result Register ISO fails with below error 2014-08-12 05:36:07,487 DEBUG [c.c.a.ApiServlet] (494953500@qtp-420407682-10:ctx-28a25fd8) ===START=== 172.16.88.7 -- GET account=test-a-TestCreateIso-W648O8domainid=af30b8e6-2219-11e4-9b06-00163e189e44name=ISO+1isfeatured=Trueispublic=Trueisextractable=Truezoneid=144183bf-f5a5-4b7e-810e-a5136db32441url=http%3A%2F%2Fnfs-server.automation.hyd.com%2Fiso%2FCentOS-6.4-i386-minimal.isoapiKey=4s6D2Ca0bs4towGp7IoFR765IrYl96zpuvYyR7i-ebWWXZD7svjDkHIUFnGgNQDLgvJgVf3LqtWmrnzmkFnfQwdisplaytext=Test+ISO+1ostypeid=aedaa6f4-2219-11e4-9b06-00163e189e44signature=TAGZ79iKy%2F3ktmiaqrli3l72Cvk%3Dcommand=registerIsoresponse=json 2014-08-12 05:36:07,686 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-157:ctx-44b5242a) VLAN is created for 2006. The uuid is 5b94ad47-f6a8-d529-544c-a6b4e8d25d0e 2014-08-12 05:36:07,698 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-157:ctx-44b5242a) Created a vif fc7f430c-7024-26f9-0fc9-d63f4e733224 on 0 2014-08-12 05:36:07,796 INFO [c.c.a.ApiServer] (494953500@qtp-420407682-10:ctx-28a25fd8 ctx-668fe4c1 ctx-51a661ba) Please specify a valid URL. URL:/iso/CentOS-6.4-i386-minimal.iso is an invalid for the format iso -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7344) VOLUME.DELETE usage event missing for VM's in ERROR state
Min Chen created CLOUDSTACK-7344: Summary: VOLUME.DELETE usage event missing for VM's in ERROR state Key: CLOUDSTACK-7344 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7344 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 Priority: Critical Fix For: 4.5.0 CloudStack is not generating the VOLUME.DELETE event for VM's which are failed to be deployed. That is if the VM deployment is failed for some reason. The VM state is updated as ERROR and cleanup is performed to release the resources allocated to the VM. As a part of cleanup volume state is updated as 'DESTROY' but no VOLUME.DELETE event is generated causing the usage issue customer is seeing now. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-7344) VOLUME.DELETE usage event missing for VM's in ERROR state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-7344: Assignee: Min Chen VOLUME.DELETE usage event missing for VM's in ERROR state - Key: CLOUDSTACK-7344 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7344 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.5.0 CloudStack is not generating the VOLUME.DELETE event for VM's which are failed to be deployed. That is if the VM deployment is failed for some reason. The VM state is updated as ERROR and cleanup is performed to release the resources allocated to the VM. As a part of cleanup volume state is updated as 'DESTROY' but no VOLUME.DELETE event is generated causing the usage issue customer is seeing now. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6940) Templates cannot be downloaded from URLs without matching file extensions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen updated CLOUDSTACK-6940: - Description: When registering templates with CloudStack, it is necessary to provide a URL from which the template can be downloaded. CloudStack validates the format of these URLs, but it does so quite aggressively, sometimes rejecting URLs that are perfectly valid. In particular, CloudStack expects and requires the URL to carry a file extension in the end that matches the expected template, eg. .vhd or .vhd.gz. If the URL doesn't have such an extension in the end, it will be rejected, even if it is a perfectly valid URL from which a VHD can be downloaded. was: When registering templates with CloudStack, it is necessary to provide a URL from which the template can be downloaded. CloudStack validates the format of these URLs, but it does so quite aggressively, sometimes rejecting URLs that are perfectly valid. In particular, CloudStack expects and requires the URL to carry a file extension that matches the expected template, eg. .vhd or .vhd.gz. If the URL doesn't have such an extension, it will be rejected, even if it is a perfectly valid URL from which a VHD can be downloaded. Templates cannot be downloaded from URLs without matching file extensions - Key: CLOUDSTACK-6940 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6940 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Fix For: 4.5.0 When registering templates with CloudStack, it is necessary to provide a URL from which the template can be downloaded. CloudStack validates the format of these URLs, but it does so quite aggressively, sometimes rejecting URLs that are perfectly valid. In particular, CloudStack expects and requires the URL to carry a file extension in the end that matches the expected template, eg. .vhd or .vhd.gz. If the URL doesn't have such an extension in the end, it will be rejected, even if it is a perfectly valid URL from which a VHD can be downloaded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-7328) [Automation] Register ISO failing with invalid iso format error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-7328: Assignee: Min Chen [Automation] Register ISO failing with invalid iso format error - Key: CLOUDSTACK-7328 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7328 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: ISO Affects Versions: 4.5.0 Environment: KVM and Xen Reporter: Rayees Namathponnan Assignee: Min Chen Priority: Blocker Fix For: 4.5.0 Attachments: vmops.log Steps to reproduce 1) Run the BVT test TestISO 2) Test case registering ISO with valid URL, Result Register ISO fails with below error 2014-08-12 05:36:07,487 DEBUG [c.c.a.ApiServlet] (494953500@qtp-420407682-10:ctx-28a25fd8) ===START=== 172.16.88.7 -- GET account=test-a-TestCreateIso-W648O8domainid=af30b8e6-2219-11e4-9b06-00163e189e44name=ISO+1isfeatured=Trueispublic=Trueisextractable=Truezoneid=144183bf-f5a5-4b7e-810e-a5136db32441url=http%3A%2F%2Fnfs-server.automation.hyd.com%2Fiso%2FCentOS-6.4-i386-minimal.isoapiKey=4s6D2Ca0bs4towGp7IoFR765IrYl96zpuvYyR7i-ebWWXZD7svjDkHIUFnGgNQDLgvJgVf3LqtWmrnzmkFnfQwdisplaytext=Test+ISO+1ostypeid=aedaa6f4-2219-11e4-9b06-00163e189e44signature=TAGZ79iKy%2F3ktmiaqrli3l72Cvk%3Dcommand=registerIsoresponse=json 2014-08-12 05:36:07,686 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-157:ctx-44b5242a) VLAN is created for 2006. The uuid is 5b94ad47-f6a8-d529-544c-a6b4e8d25d0e 2014-08-12 05:36:07,698 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-157:ctx-44b5242a) Created a vif fc7f430c-7024-26f9-0fc9-d63f4e733224 on 0 2014-08-12 05:36:07,796 INFO [c.c.a.ApiServer] (494953500@qtp-420407682-10:ctx-28a25fd8 ctx-668fe4c1 ctx-51a661ba) Please specify a valid URL. URL:/iso/CentOS-6.4-i386-minimal.iso is an invalid for the format iso -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7266) Deleting account is not cleaning the snapshot entries in secondary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093049#comment-14093049 ] Min Chen commented on CLOUDSTACK-7266: -- Please attach SSVM log as well. Based on our code and design, snapshots/4/19 folder should be removed, unless there is an error in deleting that folder. This can only be seen from your ssvm log. Deleting account is not cleaning the snapshot entries in secondary storage -- Key: CLOUDSTACK-7266 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7266 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.5.0 Reporter: manasaveloori Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Attachments: management-server.rar, mysqldump45.dmp Steps: 1. Deployed CS with ESXi5.1 2. Created VM with data disk. 3. Created snapshots on both root and data disks. 4. Now deleted the account. id: 4 account_name: test uuid: c55b8251-7bb0-4531-bd7e-7811d55160e6 type: 0 domain_id: 1 state: enabled removed: 2014-08-06 06:04:50 cleanup_needed: 0 network_domain: NULL default_zone_id: NULL default: 0 5. All the snapshots got deleted as apart of account clean up in DB mysql select * from snapshots where account_id=4\G; *** 1. row *** id: 38 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_2014080605 uuid: 716f0dd5-056e-4cab-b814-125fc6fe84e6 snapshot_type: 0 type_description: MANUAL size: 2147483648 created: 2014-08-06 05:44:44 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 2. row *** id: 39 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_20140806054650 uuid: ea949547-5ef7-40b0-99a6-152d346a0ad6 snapshot_type: 3 type_description: HOURLY size: 2147483648 created: 2014-08-06 05:46:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 3. row *** id: 40 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_20140806055150 uuid: b8af0810-b08a-40bd-a114-13a4d75907ca snapshot_type: 4 type_description: DAILY size: 2147483648 created: 2014-08-06 05:51:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 4. row *** id: 41 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_20140806055150 uuid: dda5cfb7-f5ab-4bd0-bdd3-953932e77f5e snapshot_type: 5 type_description: WEEKLY size: 2147483648 created: 2014-08-06 05:51:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 5. row *** id: 42 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 19 disk_offering_id: 3 status: Destroyed path: NULL name: testvmacct1_DATA-11_20140806055150 uuid: 69c8b7d1-baab-42ac-9a7d-dbdb0688654f snapshot_type: 3 type_description: HOURLY size: 5368709120 created: 2014-08-06 05:51:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL
[jira] [Updated] (CLOUDSTACK-7266) Deleting account is not cleaning the snapshot entries in secondary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen updated CLOUDSTACK-7266: - Assignee: manasaveloori (was: Min Chen) Assign back to reporter, please assign back to me once you attached the requested log. Deleting account is not cleaning the snapshot entries in secondary storage -- Key: CLOUDSTACK-7266 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7266 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.5.0 Reporter: manasaveloori Assignee: manasaveloori Priority: Critical Fix For: 4.5.0 Attachments: management-server.rar, mysqldump45.dmp Steps: 1. Deployed CS with ESXi5.1 2. Created VM with data disk. 3. Created snapshots on both root and data disks. 4. Now deleted the account. id: 4 account_name: test uuid: c55b8251-7bb0-4531-bd7e-7811d55160e6 type: 0 domain_id: 1 state: enabled removed: 2014-08-06 06:04:50 cleanup_needed: 0 network_domain: NULL default_zone_id: NULL default: 0 5. All the snapshots got deleted as apart of account clean up in DB mysql select * from snapshots where account_id=4\G; *** 1. row *** id: 38 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_2014080605 uuid: 716f0dd5-056e-4cab-b814-125fc6fe84e6 snapshot_type: 0 type_description: MANUAL size: 2147483648 created: 2014-08-06 05:44:44 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 2. row *** id: 39 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_20140806054650 uuid: ea949547-5ef7-40b0-99a6-152d346a0ad6 snapshot_type: 3 type_description: HOURLY size: 2147483648 created: 2014-08-06 05:46:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 3. row *** id: 40 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_20140806055150 uuid: b8af0810-b08a-40bd-a114-13a4d75907ca snapshot_type: 4 type_description: DAILY size: 2147483648 created: 2014-08-06 05:51:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 4. row *** id: 41 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 18 disk_offering_id: 1 status: Destroyed path: NULL name: testvmacct1_ROOT-11_20140806055150 uuid: dda5cfb7-f5ab-4bd0-bdd3-953932e77f5e snapshot_type: 5 type_description: WEEKLY size: 2147483648 created: 2014-08-06 05:51:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 5. row *** id: 42 data_center_id: 1 account_id: 4 domain_id: 1 volume_id: 19 disk_offering_id: 3 status: Destroyed path: NULL name: testvmacct1_DATA-11_20140806055150 uuid: 69c8b7d1-baab-42ac-9a7d-dbdb0688654f snapshot_type: 3 type_description: HOURLY size: 5368709120 created: 2014-08-06 05:51:50 removed: NULL backup_snap_id: NULL swift_id: NULL sechost_id: NULL prev_snap_id: NULL hypervisor_type: VMware version: 2.2 s3_id: NULL *** 6. row *** id: 44 data_center_id: 1
[jira] [Assigned] (CLOUDSTACK-7312) ISOs cannot be downloaded from URLs without matching file extensions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-7312: Assignee: Min Chen ISOs cannot be downloaded from URLs without matching file extensions Key: CLOUDSTACK-7312 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7312 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 Fix For: 4.5.0 When registering ISOs with CloudStack, it is necessary to provide a URL from which the ISO can be downloaded. CloudStack expects and requires the URL to carry a file extension that matches the expected iso, eg. .iso, iso.zip, iso.bz2, iso.gz. If the URL doesn't have such an extension, it will be rejected, even if it is a perfectly valid URL from which an ISO can be downloaded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7312) ISOs cannot be downloaded from URLs without matching file extensions
Min Chen created CLOUDSTACK-7312: Summary: ISOs cannot be downloaded from URLs without matching file extensions Key: CLOUDSTACK-7312 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7312 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 Fix For: 4.5.0 When registering ISOs with CloudStack, it is necessary to provide a URL from which the ISO can be downloaded. CloudStack expects and requires the URL to carry a file extension that matches the expected iso, eg. .iso, iso.zip, iso.bz2, iso.gz. If the URL doesn't have such an extension, it will be rejected, even if it is a perfectly valid URL from which an ISO can be downloaded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7312) ISOs cannot be downloaded from URLs without matching file extensions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7312. -- Resolution: Fixed ISOs cannot be downloaded from URLs without matching file extensions Key: CLOUDSTACK-7312 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7312 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 Fix For: 4.5.0 When registering ISOs with CloudStack, it is necessary to provide a URL from which the ISO can be downloaded. CloudStack expects and requires the URL to carry a file extension that matches the expected iso, eg. .iso, iso.zip, iso.bz2, iso.gz. If the URL doesn't have such an extension, it will be rejected, even if it is a perfectly valid URL from which an ISO can be downloaded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5512) template format name checking is crude and doesn't work with advanced URLs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093398#comment-14093398
]
Min Chen commented on CLOUDSTACK-5512:
--
ISO check is also removed in
https://issues.apache.org/jira/browse/CLOUDSTACK-7312.
template format name checking is crude and doesn't work with advanced URLs
--
Key: CLOUDSTACK-5512
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5512
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.0.0, 4.1.0, 4.2.0
Reporter: Marcus Sorensen
Assignee: Rohit Yadav
Fix For: 4.4.0
Template name checking currently just looks at the very end of the url
string. e.g.:
private void checkFormat(String format, String url) {
if((!url.toLowerCase().endsWith(vhd))
This breaks functionality such as registering a template via an S3 pre-signed
URL, or anything where the file extension is not the last part of the URL. We
should at least attempt to parse the URL for filename vs parameters.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7312) ISO/volume format name checking is crude and doesn't work with advanced URLs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen updated CLOUDSTACK-7312:
-
Description:
When registering ISO/Volume with CloudStack, it is necessary to provide a URL
from which the ISO/Volume can be downloaded.
SO/Volume name checking currently just looks at the very end of the url string.
e.g.:
private void checkFormat(String format, String url) {
if((!url.toLowerCase().endsWith(vhd))
This breaks functionality for S3 pre-signed URL, or anything where the file
extension is not the last part of the URL. We should at least attempt to parse
the URL for filename vs parameters.
was:
When registering ISOs with CloudStack, it is necessary to provide a URL from
which the ISO can be downloaded.
CloudStack expects and requires the URL to carry a file extension that matches
the expected iso, eg. .iso, iso.zip, iso.bz2, iso.gz. If the URL
doesn't have such an extension, it will be rejected, even if it is a perfectly
valid URL from which an ISO can be downloaded.
Summary: ISO/volume format name checking is crude and doesn't work with
advanced URLs (was: ISOs cannot be downloaded from URLs without matching file
extensions)
ISO/volume format name checking is crude and doesn't work with advanced URLs
Key: CLOUDSTACK-7312
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7312
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
Fix For: 4.5.0
When registering ISO/Volume with CloudStack, it is necessary to provide a URL
from which the ISO/Volume can be downloaded.
SO/Volume name checking currently just looks at the very end of the url
string. e.g.:
private void checkFormat(String format, String url) {
if((!url.toLowerCase().endsWith(vhd))
This breaks functionality for S3 pre-signed URL, or anything where the file
extension is not the last part of the URL. We should at least attempt to
parse the URL for filename vs parameters.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7264) NPE while creating scheduled/recurring snapshots for the removed account with cleanup_needed=1
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14090961#comment-14090961
]
Min Chen commented on CLOUDSTACK-7264:
--
Scheduled snapshots for volumes of a removed or disabled account should be
skipped.
NPE while creating scheduled/recurring snapshots for the removed account with
cleanup_needed=1
--
Key: CLOUDSTACK-7264
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7264
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Snapshot
Affects Versions: 4.5.0
Reporter: manasaveloori
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
Attachments: management-server.rar, mysqldump45.dmp
1. Created an account test with a user testuser
2. Deployed a VM with data disk.
3. Created snapshots of both root and data disks.
4. Scheduled hourly,daily,weekly,monthly snapshots of both data and root
volumes.
5. While the snapshot is in backingup state deleted the account test
Observation:
1. Account test got deleted but clean up of account failed as one of the
snapshot is in backingup state.
id: 5
account_name: acct
uuid: deb3b748-63ca-4566-8c34-a8bf6685bf11
type: 0
domain_id: 1
state: enabled
removed: 2014-08-06 07:15:23
cleanup_needed: 1
network_domain: NULL
default_zone_id: NULL
default: 0
2. Now changed the account.cleanup.interval=300sec
3. Now that account is removed with cleanup_needed=1 and scheduled snapshot
is triggered.
Snapshot creation failed with NPE and left in Allocated state
2014-08-06 12:51:42,597 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-11:ctx-0e534263 job-279) Add job-279 into job monitoring
2014-08-06 12:51:42,597 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-11:ctx-0e534263 job-279) Executing AsyncJobVO {id:279,
userId: 1, accountId: 5, instanceType: Snapshot, instanceId: 52, cmd:
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo:
{id:52,ctxUserId:1,volumeid:24,ctxAccountId:5,ctxStartEventId:1,policyid:15}
, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
result: null, initMsid: 6876007760021, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-08-06 12:51:42,600 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-11:ctx-0e534263 job-279) Unexpected exception while
executing org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd
java.lang.NullPointerException
at org.apache.cloudstack.context.CallContext.init(CallContext.java:82)
at org.apache.cloudstack.context.CallContext.register(CallContext.java:156)
at org.apache.cloudstack.context.CallContext.register(CallContext.java:143)
at org.apache.cloudstack.context.CallContext.register(CallContext.java:180)
at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:100)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
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:460)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
2014-08-06 12:51:42,606 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-11:ctx-0e534263 job-279) Complete async job-279, jobStatus:
FAILED, resultCode: 530, result:
org.apache.cloudstack.api.response.ExceptionResponse/null/
{uuidList:[],errorcode:530}
2014-08-06 12:51:42,614 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-11:ctx-0e534263 job-279) Done executing
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-279
4. Now as the snapshot state is left in allocated state...and account
cleanup after 300 secs is failing now because of snapshots left in
