[jira] [Commented] (CLOUDSTACK-9039) Log folder path Ubuntu
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14993318#comment-14993318
]
ASF GitHub Bot commented on CLOUDSTACK-9039:
Github user milamberspace commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1039#discussion_r44112143
--- Diff: python/lib/cloudutils/serviceConfigServer.py ---
@@ -107,7 +107,8 @@ def checkHostName():
bash("chown cloud.cloud /var/run/cloudstack-management.pid")
#distro like sl 6.1 needs this folder, or tomcat6 failed to start
checkHostName()
-bash("mkdir /var/log/cloudstack-management/")
+bash("mkdir /var/log/cloudstack/")
+bash("mkdir /var/log/cloudstack/management/")
--- End diff --
Perhaps use
mkdir -p /var/log/cloudstack/management/
> Log folder path Ubuntu
> --
>
> Key: CLOUDSTACK-9039
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9039
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Install and Setup
>Affects Versions: 4.6.0
>Reporter: Boris Schrijver
>Assignee: Boris Schrijver
>Priority: Minor
>
> Log folder path is incorrect during setup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14993287#comment-14993287 ] ASF GitHub Bot commented on CLOUDSTACK-8832: Github user runseb commented on the pull request: https://github.com/apache/cloudstack/pull/801#issuecomment-154335646 ok so bottom line, it seems reviews are +1 and we will merge this in 4.7. ASAP after 4.6.0 is out, taking. the only thing will be to keep an eye on it and rebase. unfortunately we cannot tag/label it for triaging properly. > Update Nuage VSP plugin to work with Nuage VSP release 3.2 > -- > > Key: CLOUDSTACK-8832 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Nick Livens >Assignee: Nick Livens > Attachments: nuageVspMarvinLogs.tar.gz > > > Nuage VSP 3.2 is being released, we want to bring the plugin up to date for > this release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9020) Metrics Views for CloudStack UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-9020: Fix Version/s: (was: 4.6.0) > Metrics Views for CloudStack UI > --- > > Key: CLOUDSTACK-9020 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9020 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future > > > In order to identify issues within CloudStack, a CloudStack admin would go > through various resources such as zones/clusters/hosts/storage pool or with > VMs or volumes, using a CLI or some other tool/script to find > CPU/Memory/Disk/Network usage of that resource to figure out if that resource > is exhausted, or having issues for example host is down, storage pool is full > etc. The metrics view aims to solve that problem by showing metrics > information for these resources in a table which would allow hierarchical > navigation to triage issue (for example, Zone -> Cluster -> Host -> Instances > -> Volumes -> Storage Pool -> Volumes), allow common operation (like those of > quick view), show cells that need attention (such as coloring a tabular cell > where threshold/disable limits have been crossed), allow data to be sorted > and refreshed. > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Metrics+Views+for+CloudStack+UI -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9040) Tomcat 7 & 8 don't work with the install scripts on Ubuntu
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14992753#comment-14992753 ] ASF GitHub Bot commented on CLOUDSTACK-9040: Github user borisroman commented on the pull request: https://github.com/apache/cloudstack/pull/1040#issuecomment-154239490 @ustcweizhou We can! Though in the current structure, if we change to support Tomcat7 we can't support Tomcat6... In my opinion, we leave it to Tomcat6 for the 4.6 release, and improve the packaging and ACS to support Tomcat 7 & 8 for the 4.7 release. > Tomcat 7 & 8 don't work with the install scripts on Ubuntu > -- > > Key: CLOUDSTACK-9040 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9040 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver >Priority: Critical > Fix For: 4.6.0 > > > Tomcat 7 & 8 don't work with the install scripts currently present on Ubuntu. > For now, we will just use Tomcat 6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9040) Tomcat 7 & 8 don't work with the install scripts on Ubuntu
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14992715#comment-14992715 ] ASF GitHub Bot commented on CLOUDSTACK-9040: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1040#issuecomment-154233552 cannot we fix the issue in tomcat7 suppport ? > Tomcat 7 & 8 don't work with the install scripts on Ubuntu > -- > > Key: CLOUDSTACK-9040 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9040 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver >Priority: Critical > Fix For: 4.6.0 > > > Tomcat 7 & 8 don't work with the install scripts currently present on Ubuntu. > For now, we will just use Tomcat 6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14992528#comment-14992528 ] ASF GitHub Bot commented on CLOUDSTACK-8832: Github user jburwell commented on the pull request: https://github.com/apache/cloudstack/pull/801#issuecomment-154200225 :+1: LGTM @nlivens excellent work -- much appreciate the hard work. > Update Nuage VSP plugin to work with Nuage VSP release 3.2 > -- > > Key: CLOUDSTACK-8832 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Nick Livens >Assignee: Nick Livens > Attachments: nuageVspMarvinLogs.tar.gz > > > Nuage VSP 3.2 is being released, we want to bring the plugin up to date for > this release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9040) Tomcat 7 & 8 don't work with the install scripts on Ubuntu
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14992299#comment-14992299 ] ASF GitHub Bot commented on CLOUDSTACK-9040: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/1040#issuecomment-154161203 LGTM We can deal with other Tomcat versions later. > Tomcat 7 & 8 don't work with the install scripts on Ubuntu > -- > > Key: CLOUDSTACK-9040 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9040 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver >Priority: Critical > Fix For: 4.6.0 > > > Tomcat 7 & 8 don't work with the install scripts currently present on Ubuntu. > For now, we will just use Tomcat 6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9040) Tomcat 7 & 8 don't work with the install scripts on Ubuntu
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14992290#comment-14992290 ] ASF GitHub Bot commented on CLOUDSTACK-9040: GitHub user borisroman opened a pull request: https://github.com/apache/cloudstack/pull/1040 CLOUDSTACK-9040: Use Tomcat6 for Debian packages. Use Tomcat6 for Debian packages. How to test: Package debian packages and install them. Will depend specifically on tomcat6 for now. You can merge this pull request into a Git repository by running: $ git pull https://github.com/borisroman/cloudstack CLOUDSTACK-9040 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1040.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1040 commit e5040b5cbdb64dcd6199b86dbfb1696c06829281 Author: Boris Schrijver Date: 2015-11-05T19:16:11Z CLOUDSTACK-9040: Use Tomcat6 for Debian packages. > Tomcat 7 & 8 don't work with the install scripts on Ubuntu > -- > > Key: CLOUDSTACK-9040 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9040 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver >Priority: Critical > Fix For: 4.6.0 > > > Tomcat 7 & 8 don't work with the install scripts currently present on Ubuntu. > For now, we will just use Tomcat 6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9040) Tomcat 7 & 8 don't work with the install scripts on Ubuntu
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Schrijver updated CLOUDSTACK-9040: Description: Tomcat 7 & 8 don't work with the install scripts currently present on Ubuntu. For now, we will just use Tomcat 6. (was: Tomcat 7 & 8 don't work with the install scripts on Ubuntu. For now, we will just use Tomcat 6.) > Tomcat 7 & 8 don't work with the install scripts on Ubuntu > -- > > Key: CLOUDSTACK-9040 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9040 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver >Priority: Critical > Fix For: 4.6.0 > > > Tomcat 7 & 8 don't work with the install scripts currently present on Ubuntu. > For now, we will just use Tomcat 6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9040) Tomcat 7 & 8 don't work with the install scripts on Ubuntu
Boris Schrijver created CLOUDSTACK-9040: --- Summary: Tomcat 7 & 8 don't work with the install scripts on Ubuntu Key: CLOUDSTACK-9040 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9040 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.6.0 Reporter: Boris Schrijver Assignee: Boris Schrijver Priority: Critical Fix For: 4.6.0 Tomcat 7 & 8 don't work with the install scripts on Ubuntu. For now, we will just use Tomcat 6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9029) Proper support to identify CentOS 7 version number on Host
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carles Figuerola updated CLOUDSTACK-9029:
-
Summary: Proper support to identify CentOS 7 version number on Host (was:
Proper support to identify CentOS 7 version number)
> Proper support to identify CentOS 7 version number on Host
> --
>
> Key: CLOUDSTACK-9029
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9029
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.5.2
> Environment: CenOS 7
>Reporter: Carles Figuerola
>Priority: Minor
>
> CentOS 7's /etc/redhat-relase doesn't have the same format as 5 or 6 and it
> makes cloudstack report the wrong version on the api.
> centos5:
> [cfiguerola@cent5 ~]$ cat /etc/redhat-release
> CentOS release 5.7 (Final)
> [cfiguerola@cent6 ~]$ cat /etc/redhat-release
> CentOS release 6.6 (Final)
> [cfiguerola@cent7~]$ cat /etc/redhat-release
> CentOS Linux release 7.1.1503 (Core)
> This makes the version on the api be:
> u'Host.OS.Version': u'release' instead of {u'Host.OS.Version': u'7.1.1503'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7097) failing to add kvm host to MS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991925#comment-14991925 ] Imran Ahmed commented on CLOUDSTACK-7097: - [~ustcweiz...@gmail.com] That was it! . In fact we had to enable virtualization in bios and that solved the issue. Thanks for your prompt reply. cheers, Imran > failing to add kvm host to MS > -- > > Key: CLOUDSTACK-7097 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7097 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: management-server.log.tar.gz > > > Repro steps: > Create a agent on rhel 6.3 > create a MS on rhel 6.3 > Try creating a zone > Bug : zone creation fails at adding host step > MS log shows : > 014-07-11 03:33:46,284 WARN [c.c.a.d.ParamGenericValidationWorker] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Received unknown parameters for > command addHost. Unknown parameters : clustertype > 2014-07-11 03:33:46,294 INFO [c.c.r.ResourceManagerImpl] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Trying to add a new host at > http://10.147.40.24 in data center 1 > 2014-07-11 03:33:46,487 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm > 2014-07-11 03:33:47,505 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm > 2014-07-11 03:33:48,556 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Executing cmd: lsmod|grep kvm > 2014-07-11 03:33:49,607 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) It's not a KVM enabled machine > 2014-07-11 03:33:49,608 WARN [c.c.r.ResourceManagerImpl] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Unable to find the server > resources at http://10.147.40.24 > 2014-07-11 03:33:49,611 INFO [c.c.u.e.CSExceptionErrorCode] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Could not find exception: > com.cloud.exception.DiscoveryException in error code list for exceptions > 2014-07-11 03:33:49,611 WARN [o.a.c.a.c.a.h.AddHostCmd] > (catalina-exec-12:ctx-007b5513 ctx-c586ed3c) Exception: > com.cloud.exception.DiscoveryException: Unable to add the host > at > com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:791) > at > com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > 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 > 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 $Proxy148.discoverHosts(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517) > at > com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) > 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:115) > at com.cloud.api.ApiServlet.doPost(ApiServlet.java:82) > at javax.servlet.http.HttpServlet.ser
[jira] [Commented] (CLOUDSTACK-9029) Proper support to identify CentOS 7 version number
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991891#comment-14991891
]
Carles Figuerola commented on CLOUDSTACK-9029:
--
I am talking about Host OS. When cloudstack-management tries to figure out the
host configuration (OS/Version/Kernel/Features) it will request
cloudstack-agent to run {noformat} scripts/vm/hypervisor/versions.sh {noformat}
to figure them out. This script returns wrong information.
The other two files, also search the file with {noformat} version.find("CentOS
release") {noformat} which will not match centos 7's format.
I't Carles, by the way ;)
> Proper support to identify CentOS 7 version number
> --
>
> Key: CLOUDSTACK-9029
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9029
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.5.2
> Environment: CenOS 7
>Reporter: Carles Figuerola
>Priority: Minor
>
> CentOS 7's /etc/redhat-relase doesn't have the same format as 5 or 6 and it
> makes cloudstack report the wrong version on the api.
> centos5:
> [cfiguerola@cent5 ~]$ cat /etc/redhat-release
> CentOS release 5.7 (Final)
> [cfiguerola@cent6 ~]$ cat /etc/redhat-release
> CentOS release 6.6 (Final)
> [cfiguerola@cent7~]$ cat /etc/redhat-release
> CentOS Linux release 7.1.1503 (Core)
> This makes the version on the api be:
> u'Host.OS.Version': u'release' instead of {u'Host.OS.Version': u'7.1.1503'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9039) Log folder path Ubuntu
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991816#comment-14991816 ] ASF GitHub Bot commented on CLOUDSTACK-9039: GitHub user borisroman opened a pull request: https://github.com/apache/cloudstack/pull/1039 CLOUDSTACK-9039: Fix paths for logging Ubuntu Management Fix paths for logging Ubuntu Management. How to test: Install via DEB packages... You can merge this pull request into a Git repository by running: $ git pull https://github.com/borisroman/cloudstack CLOUDSTACK-9039 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1039.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1039 commit 7ae487f9c6f88f2bc55e375edba3e3d9359cc10d Author: Boris Schrijver Date: 2015-11-05T15:30:14Z CLOUDSTACK-9039: Fix paths for logging Ubuntu Management > Log folder path Ubuntu > -- > > Key: CLOUDSTACK-9039 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9039 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver >Priority: Minor > > Log folder path is incorrect during setup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9039) Log folder path Ubuntu
Boris Schrijver created CLOUDSTACK-9039: --- Summary: Log folder path Ubuntu Key: CLOUDSTACK-9039 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9039 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.6.0 Reporter: Boris Schrijver Assignee: Boris Schrijver Priority: Minor Log folder path is incorrect during setup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9020) Metrics Views for CloudStack UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-9020: Status: Reviewable (was: In Progress) > Metrics Views for CloudStack UI > --- > > Key: CLOUDSTACK-9020 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9020 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.6.0 > > > In order to identify issues within CloudStack, a CloudStack admin would go > through various resources such as zones/clusters/hosts/storage pool or with > VMs or volumes, using a CLI or some other tool/script to find > CPU/Memory/Disk/Network usage of that resource to figure out if that resource > is exhausted, or having issues for example host is down, storage pool is full > etc. The metrics view aims to solve that problem by showing metrics > information for these resources in a table which would allow hierarchical > navigation to triage issue (for example, Zone -> Cluster -> Host -> Instances > -> Volumes -> Storage Pool -> Volumes), allow common operation (like those of > quick view), show cells that need attention (such as coloring a tabular cell > where threshold/disable limits have been crossed), allow data to be sorted > and refreshed. > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Metrics+Views+for+CloudStack+UI -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9020) Metrics Views for CloudStack UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991681#comment-14991681 ] ASF GitHub Bot commented on CLOUDSTACK-9020: GitHub user bhaisaab opened a pull request: https://github.com/apache/cloudstack/pull/1038 Metrics views for CloudStack UI FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Metrics+Views+for+CloudStack+UI JIRA: https://issues.apache.org/jira/browse/CLOUDSTACK-9020 You can merge this pull request into a Git repository by running: $ git pull https://github.com/shapeblue/cloudstack metrics-master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1038.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1038 commit a5341b1572eb22df1962f97257ebca38cb8056c8 Author: Rohit Yadav Date: 2015-11-05T07:03:43Z CLOUDSTACK-9020: Add new status icons and css rules Signed-off-by: Rohit Yadav commit 236578156d4b1f7ea50ab3e5e00cf85175ade863 Author: Rohit Yadav Date: 2015-11-05T07:04:26Z CLOUDSTACK-9020: Make UI pagesize configurable Add global setting that can be consumed by UI to make its pagesize for list API calls dynamic with default to 100. Signed-off-by: Rohit Yadav commit a2e94595e98c1abbd27aea2e404f68565a07f9d8 Author: Rohit Yadav Date: 2015-11-05T07:05:25Z CLOUDSTACK-9020: Method to remove last panel from the breadcrumb Adds a new method to cloudBrowser that can remove the last panel and link/ref from the breadcrumb Signed-off-by: Rohit Yadav commit baf54c6fdc60e8e24c2ccf9a3cc4b3cb21faf19e Author: Rohit Yadav Date: 2015-11-05T07:06:42Z CLOUDSTACK-9020: Implement sorting for tables Implements sorting for tables across CloudStack UI; - General alphabetic/string based sorting - Numeric sorting for columns if data appears numeric - Special sorting comparator for state columns - Avoids sorting quick view columns and other specific columns Signed-off-by: Rohit Yadav commit f7232c751e7939df1d929d65669e90694457 Author: Rohit Yadav Date: 2015-11-05T07:09:42Z CLOUDSTACK-9020: Implement collapsible columns and threshold colorings Implements following in listView that generates tabular views; - Collapsible columns in case of multi-header groupable columns - Implements threshold coloring of cells in table - Implements option to render a table that is scrollable in both x-y directions - Support to only display status icon instead of label if compact is set to true - Fixes quick-view alignment issue on Safari - If a column was previously sorted, sorts after adding new rows - If a supercolumn was collapsed, hides cell after adding new rows Signed-off-by: Rohit Yadav commit 94c4f9900196fa365df6fc32175323495892ef70 Author: Rohit Yadav Date: 2015-11-05T07:14:14Z CLOUDSTACK-9020: Metrics views for CloudStack UI Implements various metrics views based on a listView based widget that has following properties: - vertically and horizontally scrollable with pagination/infinite scrolling - sortable columns (client side) - groupable/collapsible columns - alternate row coloring - refresh button to refresh views - threshold table cell coloring - panel/breadcrumb navigation - quick view action column - translatable labels - sorts after metrics is refreshed, if a column was previously sorted - sorts after adding rows on infinite scrolling if a column was pre-sorted - Metrics views: Zones, Clusters, Hosts, Instances, Storage pools, Volumes - Resource filtering/navigation: Zones->Clusters->Hosts->Instances->Volumes, Storage Pool->Volumes Signed-off-by: Rohit Yadav > Metrics Views for CloudStack UI > --- > > Key: CLOUDSTACK-9020 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9020 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.6.0 > > > In order to identify issues within CloudStack, a CloudStack admin would go > through various resources such as zones/clusters/hosts/storage pool or with > VMs or volumes, using a CLI or some other tool/script to find > CPU/Memory/Disk/Network usage of that resource to figure out if that resource > is exhausted, or having issues for example host is down, storage pool is full > etc. The metrics view aims to solve that problem by showing
[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991673#comment-14991673 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-154062799 I am not fine with this change but must be honest and report regressions tests from the bubble: they all passed. ``` Test router internal advanced zone ... === TestName: test_02_router_internal_adv | Status : SUCCESS === ok Test restart network ... === TestName: test_03_restart_network_cleanup | Status : SUCCESS === ok Test router basic setup ... === TestName: test_05_router_basic | Status : SUCCESS === ok Test router advanced setup ... === TestName: test_06_router_advanced | Status : SUCCESS === ok Test stop router ... === TestName: test_07_stop_router | Status : SUCCESS === ok Test start router ... === TestName: test_08_start_router | Status : SUCCESS === ok Test reboot router ... === TestName: test_09_reboot_router | Status : SUCCESS === ok test_privategw_acl (integration.smoke.test_privategw_acl.TestPrivateGwACL) ... === TestName: test_privategw_acl | Status : SUCCESS === ok Test reset virtual machine on reboot ... === TestName: test_01_reset_vm_on_reboot | Status : SUCCESS === ok Test advanced zone virtual router ... === TestName: test_advZoneVirtualRouter | Status : SUCCESS === ok Test Deploy Virtual Machine ... === TestName: test_deploy_vm | Status : SUCCESS === ok Test Multiple Deploy Virtual Machine ... === TestName: test_deploy_vm_multiple | Status : SUCCESS === ok Test Stop Virtual Machine ... === TestName: test_01_stop_vm | Status : SUCCESS === ok Test Start Virtual Machine ... === TestName: test_02_start_vm | Status : SUCCESS === ok Test Reboot Virtual Machine ... === TestName: test_03_reboot_vm | Status : SUCCESS === ok Test destroy Virtual Machine ... === TestName: test_06_destroy_vm | Status : SUCCESS === ok Test recover Virtual Machine ... === TestName: test_07_restore_vm | Status : SUCCESS === ok Test migrate VM ... === TestName: test_08_migrate_vm | Status : SUCCESS === ok Test destroy(expunge) Virtual Machine ... === TestName: test_09_expunge_vm | Status : SUCCESS === ok Test to create service offering ... === TestName: test_01_create_service_offering | Status : SUCCESS === ok Test to update existing service offering ... === TestName: test_02_edit_service_offering | Status : SUCCESS === ok Test to delete service offering ... === TestName: test_03_delete_service_offering | Status : SUCCESS === ok Test for delete account ... === TestName: test_delete_account | Status : SUCCESS === ok Test for Associate/Disassociate public IP address for admin account ... === TestName: test_public_ip_admin_account | Status : SUCCESS === ok Test for Associate/Disassociate public IP address for user account ... === TestName: test_public_ip_user_account | Status : SUCCESS === ok Test for release public IP address ... === TestName: test_releaseIP | Status : SUCCESS === ok Test create VPC offering ... === TestName: test_01_create_vpc_offering | Status : SUCCESS === ok Test VPC offering without load balancing service ... === TestName: test_03_vpc_off_without_lb | Status : SUCCESS === ok Test VPC offering without static NAT service ... === TestName: test_04_vpc_off_without_static_nat | Status : SUCCESS === ok Test VPC offering without port forwarding service ... === TestName: test_05_vpc_off_without_pf | Status : SUCCESS === ok Test VPC offering with invalid services ... === TestName: test_06_vpc_off_invalid_services | Status : SUCCESS === ok Test update VPC offering ... === TestName: test_07_update_vpc_off | Status : SUCCESS === ok Test list VPC offering ... === TestName: test_08_list_vpc_off | Status : SUCCESS === ok test_09_create_redundant_vpc_offering (integration.component.test_vpc_offerings.TestVPCOffering) ... === TestName: test_09_create_redundant_vpc_offering | Status : SUCCESS === ok Test start/stop of router after addition of one guest network ... === TestName: test_01_start_stop_router_after_addition_of_one_guest_network | Status : SUCCESS === ok Test reboot of router after addition of one guest network ... === TestName: test_02_reboot_router_after_addition_of_one_guest_network | Status : SUCCESS === ok Test to change service offering of router after addition of one guest network ... === TestName: test_04_chg_srv_off_router_after_addition_of_one_guest_network | Status : SUCCESS === ok Test destroy of router after addition of one guest network ... === Test
[jira] [Commented] (CLOUDSTACK-8937) Xenserver - VM migration with storage fails in a clustered management server setup
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991590#comment-14991590
]
ASF GitHub Bot commented on CLOUDSTACK-8937:
Github user atrbgithub commented on the pull request:
https://github.com/apache/cloudstack/pull/925#issuecomment-154042688
Fix for master branch has been proposed here
https://github.com/apache/cloudstack/pull/1037
> Xenserver - VM migration with storage fails in a clustered management server
> setup
> --
>
> Key: CLOUDSTACK-8937
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8937
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.5.2
>Reporter: CS User
>
> When using the migrateVirtualMachineWithVolume, in a clustered management
> server environment, migrations intermittently fail. This appears to be a
> similar issue to this jira ticket:
> https://issues.apache.org/jira/browse/CLOUDSTACK-8412
> For reference, the error is:
> {noformat}
> ERROR [c.c.a.t.Request] (AgentManager-Handler-11:null) Caught problem with
> [{"com.cloud.agent.api.MigrateWithStorageCommand":{"vm":{"id":26631,"name":"i-2-26631-VM","bootloader":"PyGrub","type":"Us
> er","cpus":1,"minSpeed":1200,"maxSpeed":1200,"minRam":536870912,"maxRam":536870912,"arch":"x86_64","os":"CentOS
> 5.6 (64-bit)","platformEmulator":"CentOS 5
> (64-bit)","bootArgs":"","enableHA":false,"
> limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"","params":{"memoryOvercommitRatio":"1","platform":"viridian:true;acpi:1;apic:true;pae:true;nx:t
> rue","hypervisortoolsversion":"xenserver56","cpuOvercommitRatio":"4"},"uuid":"b37e76e8-e19a-4100-bf1c-1ee8eba674f2","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"8f51
> e73f-9bfc-4a37-bf86-664067a2cf40","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"b114d58e-a37a-6433-c0ff-07f3613a3c68","id":219,"poolType":"LVM","ho
> st":"192.168.97.2","path":"lvm","port":0,"url":"LVM://192.168.97.2/lvm/?ROLE\u003dPrimary\u0026STOREUUID\u003db114d58e-a37a-6433-c0ff-07f3613a3c68"}},"name":"ROOT-26631","size":21474836480,"path":"48
> fe494b-ee02-4f08-b7aa-975baecd7b3e","volumeId":119075,"vmName":"i-2-26631-VM","accountId":2,"format":"VHD","provisioningType":"THIN","id":119075,"deviceId":0,"cacheMode":"NONE","hypervisorType":"Xe
> nServer"}},"diskSeq":0,"path":"48fe494b-ee02-4f08-b7aa-975baecd7b3e","type":"ROOT","_details":{"managed":"false","storagePort":"0","storageHost":"192.168.97.2","volumeSize":"21474836480"}},{"data":{
> "org.apache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":[{"deviceId":0,"networkRateMbps":2000,"defaultNic":true,"pxe
> Disable":false,"nicUuid":"aaef8c14-784c-403f-91fc-b6a3167f2595","uuid":"508d0384-5bf0-4434-8155-0b5bb1b33b43","ip":"192.168.8.112","netmask":"255.255.254.0","gateway":"192.168.9.254","mac":"06:68:80:
> 00:00:7f","dns1":"192.168.0.224","dns2":"192.168.0.224","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://untagged","isSecurityGroupEnabled":true,"name":"CS-Guest-Public"}],"vcpuMaxLimit":
> 16},"volumeToFiler":{"Vol[119075|ROOT|48fe494b-ee02-4f08-b7aa-975baecd7b3e|21474836480]":{"id":223,"uuid":"bc01ca2b-e6d8-a856-27b5-6f6b55a06b1d","host":"192.168.97.1","path":"lvm","port":0,"type":"L
> VM"}},"contextMap":{"job":"job-347068/job-347069"},"wait":0}}]
> com.google.gson.JsonParseException: Expecting object found:
> "Vol[119075|ROOT|48fe494b-ee02-4f08-b7aa-975baecd7b3e|21474836480]"
> at
> com.google.gson.JsonObjectDeserializationVisitor.visitFieldUsingCustomHandler(JsonObjectDeserializationVisitor.java:100)
> at
> com.google.gson.ReflectingFieldNavigator.visitFieldsReflectively(ReflectingFieldNavigator.java:63)
> at com.google.gson.ObjectNavigator.accept(ObjectNavigator.java:120)
> at
> com.google.gson.JsonDeserializationContextDefault.fromJsonPrimitive(JsonDeserializationContextDefault.java:85)
> at
> com.google.gson.JsonDeserializationContextDefault.deserialize(JsonDeserializationContextDefault.java:56)
> at com.google.gson.MapTypeAdapter.deserialize(MapTypeAdapter.java:67)
> at com.google.gson.MapTypeAdapter.deserialize(MapTypeAdapter.java:33)
> at
> com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserializerExceptionWrapper.java:51)
> at
> com.google.gson.JsonDeserializationVisitor.invokeCustomDeserializer(JsonDeserializationVisitor.java:92)
> at
> com.google.gson.JsonObjectDeserializationVisitor.visitFieldUsingCustomHandler(JsonObjectDeserializationVisitor.java:117)
> at
[jira] [Commented] (CLOUDSTACK-8937) Xenserver - VM migration with storage fails in a clustered management server setup
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991586#comment-14991586
]
ASF GitHub Bot commented on CLOUDSTACK-8937:
GitHub user atrbgithub opened a pull request:
https://github.com/apache/cloudstack/pull/1037
Fix for CLOUDSTACK-8937 - XenServer migrations with storage failing i…
…n clustered management server environment
This pull request relates to the following Jira bug report:
https://issues.apache.org/jira/browse/CLOUDSTACK-8937
A previous fix was proposed for the 4.5 branch here:
https://github.com/apache/cloudstack/pull/925
This was tested within a working environment and everything appeared to
work fine.
@remibergsma Unfortunately I have not been able to test this within a
running environment. Everything appears to compile ok and tests pass. I believe
you are much further along in the Cloudstack automated testing arena, so I'm
not sure if this is something you would be able to test at some point in the
future?
If not I will be able to test it when my current workload permits and
report back here with my findings.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/autotraderuk/cloudstack 4.6-CS-8937
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/1037.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1037
commit 1e505e08883f4735c70e9d0de03d24efe990ed2a
Author: atrbgithub
Date: 2015-11-05T11:53:55Z
Fix for CLOUDSTACK-8937 - XenServer migrations with storage failing in
clustered management server environment
> Xenserver - VM migration with storage fails in a clustered management server
> setup
> --
>
> Key: CLOUDSTACK-8937
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8937
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.5.2
>Reporter: CS User
>
> When using the migrateVirtualMachineWithVolume, in a clustered management
> server environment, migrations intermittently fail. This appears to be a
> similar issue to this jira ticket:
> https://issues.apache.org/jira/browse/CLOUDSTACK-8412
> For reference, the error is:
> {noformat}
> ERROR [c.c.a.t.Request] (AgentManager-Handler-11:null) Caught problem with
> [{"com.cloud.agent.api.MigrateWithStorageCommand":{"vm":{"id":26631,"name":"i-2-26631-VM","bootloader":"PyGrub","type":"Us
> er","cpus":1,"minSpeed":1200,"maxSpeed":1200,"minRam":536870912,"maxRam":536870912,"arch":"x86_64","os":"CentOS
> 5.6 (64-bit)","platformEmulator":"CentOS 5
> (64-bit)","bootArgs":"","enableHA":false,"
> limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"","params":{"memoryOvercommitRatio":"1","platform":"viridian:true;acpi:1;apic:true;pae:true;nx:t
> rue","hypervisortoolsversion":"xenserver56","cpuOvercommitRatio":"4"},"uuid":"b37e76e8-e19a-4100-bf1c-1ee8eba674f2","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"8f51
> e73f-9bfc-4a37-bf86-664067a2cf40","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"b114d58e-a37a-6433-c0ff-07f3613a3c68","id":219,"poolType":"LVM","ho
> st":"192.168.97.2","path":"lvm","port":0,"url":"LVM://192.168.97.2/lvm/?ROLE\u003dPrimary\u0026STOREUUID\u003db114d58e-a37a-6433-c0ff-07f3613a3c68"}},"name":"ROOT-26631","size":21474836480,"path":"48
> fe494b-ee02-4f08-b7aa-975baecd7b3e","volumeId":119075,"vmName":"i-2-26631-VM","accountId":2,"format":"VHD","provisioningType":"THIN","id":119075,"deviceId":0,"cacheMode":"NONE","hypervisorType":"Xe
> nServer"}},"diskSeq":0,"path":"48fe494b-ee02-4f08-b7aa-975baecd7b3e","type":"ROOT","_details":{"managed":"false","storagePort":"0","storageHost":"192.168.97.2","volumeSize":"21474836480"}},{"data":{
> "org.apache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":[{"deviceId":0,"networkRateMbps":2000,"defaultNic":true,"pxe
> Disable":false,"nicUuid":"aaef8c14-784c-403f-91fc-b6a3167f2595","uuid":"508d0384-5bf0-4434-8155-0b5bb1b33b43","ip":"192.168.8.112","netmask":"255.255.254.0","gateway":"192.168.9.254","mac":"06:68:80:
> 00:00:7f","dns1":"192.168.0.224","dns2":"192.168.0.224","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://untagged","isSecurityGroupEnabled":true,"name":"CS-Guest-Public"}],"vcpuMaxLimit":
> 16},"volumeToFiler":{"Vol[119075|ROOT|48fe494b-ee02-4f08-b7aa-975baecd7b3e|21474836480]":{"id":223,"uuid":"bc01ca2b
[jira] [Commented] (CLOUDSTACK-9038) Infrastructure tab is slow because of synchronous API calls
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991560#comment-14991560 ] ASF GitHub Bot commented on CLOUDSTACK-9038: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1036#issuecomment-154035977 Thanks @rags22489664 sounds good! Will try to test it soon. > Infrastructure tab is slow because of synchronous API calls > --- > > Key: CLOUDSTACK-9038 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9038 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.3 >Reporter: Ramamurti Subramanian >Assignee: Ramamurti Subramanian > > We make multiple synchronous API calls in a sequential order before showing > the count of various elements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991559#comment-14991559 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user koushik-das commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-154035894 @DaanHoogland If you look at ApiResponseGsonHelper.java in this PR there are GSon builders private static final GsonBuilder s_gBuilder; private static final GsonBuilder s_gLogBuilder; Similarly for agent commands, if you look at GsonHelper.java there are 2 of them protected static final Gson s_gson; protected static final Gson s_gogger; > listAPIs are taking too long to return results > -- > > Key: CLOUDSTACK-8485 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.1, 4.6.0 >Reporter: Sowmya Krishnan >Assignee: Koushik Das > Fix For: 4.6.0 > > > listAPIs are taking significantly longer than before (4.2.x) > I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K > Routers. Here are few results: > listVirtualMachines is taking > 25 sec to return with pagesize set to 50. > This is in comparison to 2 sec in earlier cases such as 4.2. > listVolumes with pagesize = 1000 took more than 10 mins and finally times out. > Further observations show that there are also lot of slow queries being > logged in catalina.out and in MySQL slow query logs. I am not sure if this > could be the reason for DB performance getting impacted in turn causing an > impact on listAPIs too. > Here's a sample of slow queries from catalina.out: > Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637759, statement-id: 3218312, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, > user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE > user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637843, statement-id: 3218311, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, > host.resource, host.fs_type, host.available, host.setup, host.resource_state, > host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, > host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, > host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, > host.mgmt_server_id, host.dom0_memory, host.version, host.created, > host.removed FROM host WHERE host.id = 345 AND host.removed IS NULL > Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 6458 ms, connection-id: 637623, statement-id: 3218243, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 > ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref INNER > JOIN host ON storage_pool_host_ref.host_id=host.id WHERE > storage_pool_host_ref.pool_id = 197 AND (host.status = 'Up' AND > host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 2402 ms, connection-id: 637754, statement-id: 3218371, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_ad
[jira] [Commented] (CLOUDSTACK-9038) Infrastructure tab is slow because of synchronous API calls
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991555#comment-14991555 ] ASF GitHub Bot commented on CLOUDSTACK-9038: GitHub user rags22489664 opened a pull request: https://github.com/apache/cloudstack/pull/1036 CLOUDSTACK-9038 - Infrastructure tab is slow because of synchronous API calls Making parallel asynchronous calls to speed up the infrastructure page. You can merge this pull request into a Git repository by running: $ git pull https://github.com/rags22489664/cloudstack master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1036.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1036 commit fc0ed447e5971d7ceaf5a18d4a181b01f594394f Author: ramamurtis Date: 2015-11-05T11:24:05Z CLOUDSTACK-9038 - Infrastructure tab is slow because of synchronous API calls Making parallel asynchronous calls to speed up the page. > Infrastructure tab is slow because of synchronous API calls > --- > > Key: CLOUDSTACK-9038 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9038 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.3 >Reporter: Ramamurti Subramanian >Assignee: Ramamurti Subramanian > > We make multiple synchronous API calls in a sequential order before showing > the count of various elements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9038) Infrastructure tab is slow because of synchronous API calls
Ramamurti Subramanian created CLOUDSTACK-9038: - Summary: Infrastructure tab is slow because of synchronous API calls Key: CLOUDSTACK-9038 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9038 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.3 Reporter: Ramamurti Subramanian Assignee: Ramamurti Subramanian We make multiple synchronous API calls in a sequential order before showing the count of various elements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991540#comment-14991540 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-154032129 @koushik-das you said 'LogLevel is used in the latter one only.'. That is not true, I think. see com.cloud.agent.transport.RequestTest > listAPIs are taking too long to return results > -- > > Key: CLOUDSTACK-8485 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.1, 4.6.0 >Reporter: Sowmya Krishnan >Assignee: Koushik Das > Fix For: 4.6.0 > > > listAPIs are taking significantly longer than before (4.2.x) > I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K > Routers. Here are few results: > listVirtualMachines is taking > 25 sec to return with pagesize set to 50. > This is in comparison to 2 sec in earlier cases such as 4.2. > listVolumes with pagesize = 1000 took more than 10 mins and finally times out. > Further observations show that there are also lot of slow queries being > logged in catalina.out and in MySQL slow query logs. I am not sure if this > could be the reason for DB performance getting impacted in turn causing an > impact on listAPIs too. > Here's a sample of slow queries from catalina.out: > Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637759, statement-id: 3218312, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, > user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE > user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637843, statement-id: 3218311, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, > host.resource, host.fs_type, host.available, host.setup, host.resource_state, > host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, > host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, > host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, > host.mgmt_server_id, host.dom0_memory, host.version, host.created, > host.removed FROM host WHERE host.id = 345 AND host.removed IS NULL > Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 6458 ms, connection-id: 637623, statement-id: 3218243, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 > ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref INNER > JOIN host ON storage_pool_host_ref.host_id=host.id WHERE > storage_pool_host_ref.pool_id = 197 AND (host.status = 'Up' AND > host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 2402 ms, connection-id: 637754, statement-id: 3218371, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, > host.resource, host.fs_type, host.available, host.setup, host.resource_state, > host.hypervisor_version, host.upd
[jira] [Updated] (CLOUDSTACK-9024) Restart network fails if redundant router is missing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dsclose updated CLOUDSTACK-9024: Description: Edit: Included details discussed in comments below. Restart network action fails if a network is missing a redundant virtual router. This occurs if triggered via the UI (Networks -> Select Network -> Restart -> Clean-ip: False -> OK) or via the API. Steps to reproduce: 1. Create a redundant router network offering. 2. Create a network using the redundant router network offering. 3. Destroy a redundant router from the network. Leave one functioning. 4. Initiate the restart network action or restartNetwork API call with clean-up set to False. Expected Behaviour: -- Cloudstack should boot a new redundant virtual router to replace the missing router. The Network Restart action should return successfully. This is consistent with the Cloudstack documentation on how to replace faulty virtual routers: "If you are sure that a virtual router is down forever, or no longer functions as expected, destroy it. ... Recreate the missing router by using the restartNetwork API with cleanup=false parameter." http://cloudstack-administration.readthedocs.org/en/latest/troubleshooting.html#recovering-a-lost-virtual-router Observed Behaviour -- Cloudstack boots a replacement redundant router as expected. The API call, however, returns a "Network Restart Failed" result. The same is true if the restart is triggered from the Web UI. The Cloudstack logs report "Can't find all necessary running routers!" Hypothesis -- This appears to have been introduced as part of CLOUDSTACK-6433. Relevant commit: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=59a9db3 Commit title: Don't return success if only one RvR builds successfully. The code included in that commit throws an exception "Can't find all necessary running routers!" if a network implementation action doesn't create two virtual routers. Possibly related issues - This may be related to issues Cloudstack-8844 and Cloudstack-8787. I don't have a proper environment to test whether Cloudstack-8844 has resolved this issue as well. Timeline: --- 2015-11-03 17:12:08,256 Destroying router "r-985-VM". 2015-11-03 17:12:24,511 Performing network restart. 2015-11-03 17:14:02,851 Failed to restart network Management Log Sample - 2015-11-03 17:12:14,943 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-12:ctx-a671c200 job-163/job-164) Remove job-164 from job monitoring 2015-11-03 17:12:15,739 INFO [o.a.c.s.v.VolumeServiceImpl] (API-Job-Executor-12:ctx-33b24483 job-163 ctx-4d95a357) Volume 985 is not referred anywhere, remove it from volumes table 2015-11-03 17:12:15,850 INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-12:ctx-33b24483 job-163) Remove job-163 from job monitoring 2015-11-03 17:12:18,698 INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-13:ctx-c29ad7f0 job-165) Add job-165 into job monitoring 2015-11-03 17:12:18,985 INFO [c.c.n.r.VirtualNetworkApplianceManagerImpl] (API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Use same MAC as previous RvR, the MAC is 06:9c:86:00:00:0e 2015-11-03 17:12:19,829 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-13:ctx-06672650 job-165/job-166) Add job-166 into job monitoring 2015-11-03 17:12:20,078 INFO [c.c.s.StorageManagerImpl] (Work-Job-Executor-13:ctx-06672650 job-165/job-166 ctx-81c163bb) Storage pool null (1) does not supply IOPS capacity, assuming enough capacity 2015-11-03 17:12:40,248 INFO [c.c.v.VirtualMachineManagerImpl] (DirectAgentCronJob-492:ctx-1fb6ecea) There is pending job or HA tasks working on the VM. vm id: 992, postpone power-change report by resetting power-change counters 2015-11-03 17:13:40,384 INFO [c.c.v.VirtualMachineManagerImpl] (DirectAgentCronJob-280:ctx-846ef4f0) There is pending job or HA tasks working on the VM. vm id: 992, postpone power-change report by resetting power-change counters 2015-11-03 17:13:49,799 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] (AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) Begin cleanup expired async-jobs 2015-11-03 17:13:49,825 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] (AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) End cleanup expired async-jobs 2015-11-03 17:13:55,688 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-13:ctx-06672650 job-165/job-166) Remove job-166 from job monitoring 2015-11-03 17:13:55,730 WARN [o.a.c.e.o.NetworkOrchestrator] (API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Failed to implement network Ntwk[208|Guest|15] elements and resources as a part of network restart due to com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is unreachable: Can't find all necessary running routers! at com.clou
[jira] [Updated] (CLOUDSTACK-9024) Restart network fails if redundant router is missing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dsclose updated CLOUDSTACK-9024: Description: Edit: Included details discussed in comments below. Restart network action fails if a network is missing a redundant virtual router. This occurs if triggered via the UI (Networks -> Select Network -> Restart -> Clean-ip: False -> OK) or via the API. Steps to reproduce: 1. Create a redundant router network offering. 2. Create a network using the redundant router network offering. 3. Destroy a redundant router from the network. Leave one functioning. 4. Initiate the restart network action or restartNetwork API call with clean-up set to False. Expected Behaviour: -- Cloudstack should boot a new redundant virtual router to replace the missing router. The Network Restart action should return successfully. This is consistent with the Cloudstack documentation on how to replace faulty virtual routers: "If you are sure that a virtual router is down forever, or no longer functions as expected, destroy it. ... Recreate the missing router by using the restartNetwork API with cleanup=false parameter." http://cloudstack-administration.readthedocs.org/en/latest/troubleshooting.html#recovering-a-lost-virtual-router Observed Behaviour -- Cloudstack boots a replacement redundant router as expected. The API call, however, returns a "Network Restart Failed" result. The same is true if the restart is triggered from the Web UI. The Cloudstack logs report "Can't find all necessary running routers!" Hypothesis -- This appears to have been introduced as part of CLOUDSTACK-6433. Relevant commit: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=59a9db3 Commit title: Don't return success if only one RvR builds successfully. The code included in that commit throws an exception "Can't find all necessary running routers!" if a network implementation action doesn't create two virtual routers. Possibly related issues - Timeline: --- 2015-11-03 17:12:08,256 Destroying router "r-985-VM". 2015-11-03 17:12:24,511 Performing network restart. 2015-11-03 17:14:02,851 Failed to restart network Management Log Sample - 2015-11-03 17:12:14,943 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-12:ctx-a671c200 job-163/job-164) Remove job-164 from job monitoring 2015-11-03 17:12:15,739 INFO [o.a.c.s.v.VolumeServiceImpl] (API-Job-Executor-12:ctx-33b24483 job-163 ctx-4d95a357) Volume 985 is not referred anywhere, remove it from volumes table 2015-11-03 17:12:15,850 INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-12:ctx-33b24483 job-163) Remove job-163 from job monitoring 2015-11-03 17:12:18,698 INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-13:ctx-c29ad7f0 job-165) Add job-165 into job monitoring 2015-11-03 17:12:18,985 INFO [c.c.n.r.VirtualNetworkApplianceManagerImpl] (API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Use same MAC as previous RvR, the MAC is 06:9c:86:00:00:0e 2015-11-03 17:12:19,829 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-13:ctx-06672650 job-165/job-166) Add job-166 into job monitoring 2015-11-03 17:12:20,078 INFO [c.c.s.StorageManagerImpl] (Work-Job-Executor-13:ctx-06672650 job-165/job-166 ctx-81c163bb) Storage pool null (1) does not supply IOPS capacity, assuming enough capacity 2015-11-03 17:12:40,248 INFO [c.c.v.VirtualMachineManagerImpl] (DirectAgentCronJob-492:ctx-1fb6ecea) There is pending job or HA tasks working on the VM. vm id: 992, postpone power-change report by resetting power-change counters 2015-11-03 17:13:40,384 INFO [c.c.v.VirtualMachineManagerImpl] (DirectAgentCronJob-280:ctx-846ef4f0) There is pending job or HA tasks working on the VM. vm id: 992, postpone power-change report by resetting power-change counters 2015-11-03 17:13:49,799 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] (AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) Begin cleanup expired async-jobs 2015-11-03 17:13:49,825 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] (AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) End cleanup expired async-jobs 2015-11-03 17:13:55,688 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-13:ctx-06672650 job-165/job-166) Remove job-166 from job monitoring 2015-11-03 17:13:55,730 WARN [o.a.c.e.o.NetworkOrchestrator] (API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Failed to implement network Ntwk[208|Guest|15] elements and resources as a part of network restart due to com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is unreachable: Can't find all necessary running routers! at com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:202) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNet
[jira] [Updated] (CLOUDSTACK-9024) Restart network fails if redundant router is missing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dsclose updated CLOUDSTACK-9024: Description: Restart network action fails if a network is missing a redundant virtual router. This occurs if triggered via the UI (Networks -> Select Network -> Restart -> Clean-ip: False -> OK) or via the API. Steps to reproduce: 1. Create a redundant router network offering. 2. Create a network using the redundant router network offering. 3. Destroy a redundant router from the network. Leave one functioning. 4. Initiate the restart network action or restartNetwork API call with clean-up set to False. Expected Behaviour: -- Cloudstack should boot a new redundant virtual router to replace the missing router. The Network Restart action should return successfully. This is consistent with the Cloudstack documentation on how to replace faulty virtual routers: "If you are sure that a virtual router is down forever, or no longer functions as expected, destroy it. ... Recreate the missing router by using the restartNetwork API with cleanup=false parameter." http://cloudstack-administration.readthedocs.org/en/latest/troubleshooting.html#recovering-a-lost-virtual-router Observed Behaviour -- Cloudstack boots a replacement redundant router as expected. The API call, however, returns a "Network Restart Failed" result. The same is true if the restart is triggered from the Web UI. The Cloudstack logs report "Can't find all necessary running routers!" Hypothesis -- Timeline: --- 2015-11-03 17:12:08,256 Destroying router "r-985-VM". 2015-11-03 17:12:24,511 Performing network restart. 2015-11-03 17:14:02,851 Failed to restart network Management Log Sample - 2015-11-03 17:12:14,943 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-12:ctx-a671c200 job-163/job-164) Remove job-164 from job monitoring 2015-11-03 17:12:15,739 INFO [o.a.c.s.v.VolumeServiceImpl] (API-Job-Executor-12:ctx-33b24483 job-163 ctx-4d95a357) Volume 985 is not referred anywhere, remove it from volumes table 2015-11-03 17:12:15,850 INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-12:ctx-33b24483 job-163) Remove job-163 from job monitoring 2015-11-03 17:12:18,698 INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-13:ctx-c29ad7f0 job-165) Add job-165 into job monitoring 2015-11-03 17:12:18,985 INFO [c.c.n.r.VirtualNetworkApplianceManagerImpl] (API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Use same MAC as previous RvR, the MAC is 06:9c:86:00:00:0e 2015-11-03 17:12:19,829 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-13:ctx-06672650 job-165/job-166) Add job-166 into job monitoring 2015-11-03 17:12:20,078 INFO [c.c.s.StorageManagerImpl] (Work-Job-Executor-13:ctx-06672650 job-165/job-166 ctx-81c163bb) Storage pool null (1) does not supply IOPS capacity, assuming enough capacity 2015-11-03 17:12:40,248 INFO [c.c.v.VirtualMachineManagerImpl] (DirectAgentCronJob-492:ctx-1fb6ecea) There is pending job or HA tasks working on the VM. vm id: 992, postpone power-change report by resetting power-change counters 2015-11-03 17:13:40,384 INFO [c.c.v.VirtualMachineManagerImpl] (DirectAgentCronJob-280:ctx-846ef4f0) There is pending job or HA tasks working on the VM. vm id: 992, postpone power-change report by resetting power-change counters 2015-11-03 17:13:49,799 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] (AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) Begin cleanup expired async-jobs 2015-11-03 17:13:49,825 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] (AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) End cleanup expired async-jobs 2015-11-03 17:13:55,688 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-13:ctx-06672650 job-165/job-166) Remove job-166 from job monitoring 2015-11-03 17:13:55,730 WARN [o.a.c.e.o.NetworkOrchestrator] (API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Failed to implement network Ntwk[208|Guest|15] elements and resources as a part of network restart due to com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is unreachable: Can't find all necessary running routers! at com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:202) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1103) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2546) at com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1891) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Delegating
[jira] [Updated] (CLOUDSTACK-9024) Restart network fails if redundant router is missing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dsclose updated CLOUDSTACK-9024: Description: Restart network action fails if a network is missing a redundant virtual router. This occurs if triggered via the UI (Networks -> Select Network -> Restart -> Clean-ip: False -> OK) or via the API. Steps to reproduce: 1. Create a redundant router network offering. 2. Create a network using the redundant router network offering. 3. Destroy a redundant router from the network. Leave one functioning. 4. Initiate the restart network action or restartNetwork API call with clean-up set to False. Expected Behaviour: -- Cloudstack should boot a new redundant virtual router to replace the missing router. The Network Restart action should return successfully. This is consistent with the Cloudstack documentation on how to replace faulty virtual routers: "If you are sure that a virtual router is down forever, or no longer functions as expected, destroy it. ... Recreate the missing router by using the restartNetwork API with cleanup=false parameter." http://cloudstack-administration.readthedocs.org/en/latest/troubleshooting.html#recovering-a-lost-virtual-router Observed Behaviour -- Cloudstack boots a replacement redundant router as expected. The API call, however, returns a "Network Restart Failed" result. The same is true if the restart is triggered from the Web UI. The Cloudstack logs report that Can't find all necessary running routers! Timeline: --- 2015-11-03 17:12:08,256 Destroying router "r-985-VM". 2015-11-03 17:12:24,511 Performing network restart. 2015-11-03 17:14:02,851 Failed to restart network Management Log Sample - 2015-11-03 17:12:14,943 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-12:ctx-a671c200 job-163/job-164) Remove job-164 from job monitoring 2015-11-03 17:12:15,739 INFO [o.a.c.s.v.VolumeServiceImpl] (API-Job-Executor-12:ctx-33b24483 job-163 ctx-4d95a357) Volume 985 is not referred anywhere, remove it from volumes table 2015-11-03 17:12:15,850 INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-12:ctx-33b24483 job-163) Remove job-163 from job monitoring 2015-11-03 17:12:18,698 INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-13:ctx-c29ad7f0 job-165) Add job-165 into job monitoring 2015-11-03 17:12:18,985 INFO [c.c.n.r.VirtualNetworkApplianceManagerImpl] (API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Use same MAC as previous RvR, the MAC is 06:9c:86:00:00:0e 2015-11-03 17:12:19,829 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-13:ctx-06672650 job-165/job-166) Add job-166 into job monitoring 2015-11-03 17:12:20,078 INFO [c.c.s.StorageManagerImpl] (Work-Job-Executor-13:ctx-06672650 job-165/job-166 ctx-81c163bb) Storage pool null (1) does not supply IOPS capacity, assuming enough capacity 2015-11-03 17:12:40,248 INFO [c.c.v.VirtualMachineManagerImpl] (DirectAgentCronJob-492:ctx-1fb6ecea) There is pending job or HA tasks working on the VM. vm id: 992, postpone power-change report by resetting power-change counters 2015-11-03 17:13:40,384 INFO [c.c.v.VirtualMachineManagerImpl] (DirectAgentCronJob-280:ctx-846ef4f0) There is pending job or HA tasks working on the VM. vm id: 992, postpone power-change report by resetting power-change counters 2015-11-03 17:13:49,799 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] (AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) Begin cleanup expired async-jobs 2015-11-03 17:13:49,825 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] (AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) End cleanup expired async-jobs 2015-11-03 17:13:55,688 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-13:ctx-06672650 job-165/job-166) Remove job-166 from job monitoring 2015-11-03 17:13:55,730 WARN [o.a.c.e.o.NetworkOrchestrator] (API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Failed to implement network Ntwk[208|Guest|15] elements and resources as a part of network restart due to com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is unreachable: Can't find all necessary running routers! at com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:202) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1103) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2546) at com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1891) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:4
[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991521#comment-14991521 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user koushik-das commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-154030678 @DaanHoogland That's right. I had already mentioned about the agent commands in one of my previous comments > listAPIs are taking too long to return results > -- > > Key: CLOUDSTACK-8485 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.1, 4.6.0 >Reporter: Sowmya Krishnan >Assignee: Koushik Das > Fix For: 4.6.0 > > > listAPIs are taking significantly longer than before (4.2.x) > I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K > Routers. Here are few results: > listVirtualMachines is taking > 25 sec to return with pagesize set to 50. > This is in comparison to 2 sec in earlier cases such as 4.2. > listVolumes with pagesize = 1000 took more than 10 mins and finally times out. > Further observations show that there are also lot of slow queries being > logged in catalina.out and in MySQL slow query logs. I am not sure if this > could be the reason for DB performance getting impacted in turn causing an > impact on listAPIs too. > Here's a sample of slow queries from catalina.out: > Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637759, statement-id: 3218312, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, > user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE > user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637843, statement-id: 3218311, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, > host.resource, host.fs_type, host.available, host.setup, host.resource_state, > host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, > host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, > host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, > host.mgmt_server_id, host.dom0_memory, host.version, host.created, > host.removed FROM host WHERE host.id = 345 AND host.removed IS NULL > Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 6458 ms, connection-id: 637623, statement-id: 3218243, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 > ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref INNER > JOIN host ON storage_pool_host_ref.host_id=host.id WHERE > storage_pool_host_ref.pool_id = 197 AND (host.status = 'Up' AND > host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 2402 ms, connection-id: 637754, statement-id: 3218371, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, > host.resource, host.fs_type, host.available, host.setup, host.resource_state, > host.hypervisor_version, host.update_count, host.uuid, host.d
[jira] [Updated] (CLOUDSTACK-9024) Restart network fails if redundant router is missing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dsclose updated CLOUDSTACK-9024: Description: Restart network action fails if a network is missing a redundant virtual router. This occurs if triggered via the UI (Networks -> Select Network -> Restart -> Clean-ip: False -> OK) or via the API. Steps to reproduce: 1. Create a redundant router network offering. 2. Create a network using the redundant router network offering. 3. Destroy a redundant router from the network. Leave one functioning. 4. Initiate the restart network action or restartNetwork API call with clean-up set to False. Expected Behaviour: -- Cloudstack should boot a new redundant virtual router to replace the missing router. The Network Restart action should return successfully. This is consistent with the Cloudstack documentation on how to replace faulty virtual routers: Actual Behaviour: --- Cloudstack boots a replacement redundant router but the API call returns unsucessful. The Web UI reports that the router fails. Timeline: --- 2015-11-03 17:12:08,256 Destroying router "r-985-VM". 2015-11-03 17:12:24,511 Performing network restart. 2015-11-03 17:14:02,851 Failed to restart network Management Log Sample - 2015-11-03 17:12:14,943 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-12:ctx-a671c200 job-163/job-164) Remove job-164 from job monitoring 2015-11-03 17:12:15,739 INFO [o.a.c.s.v.VolumeServiceImpl] (API-Job-Executor-12:ctx-33b24483 job-163 ctx-4d95a357) Volume 985 is not referred anywhere, remove it from volumes table 2015-11-03 17:12:15,850 INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-12:ctx-33b24483 job-163) Remove job-163 from job monitoring 2015-11-03 17:12:18,698 INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-13:ctx-c29ad7f0 job-165) Add job-165 into job monitoring 2015-11-03 17:12:18,985 INFO [c.c.n.r.VirtualNetworkApplianceManagerImpl] (API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Use same MAC as previous RvR, the MAC is 06:9c:86:00:00:0e 2015-11-03 17:12:19,829 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-13:ctx-06672650 job-165/job-166) Add job-166 into job monitoring 2015-11-03 17:12:20,078 INFO [c.c.s.StorageManagerImpl] (Work-Job-Executor-13:ctx-06672650 job-165/job-166 ctx-81c163bb) Storage pool null (1) does not supply IOPS capacity, assuming enough capacity 2015-11-03 17:12:40,248 INFO [c.c.v.VirtualMachineManagerImpl] (DirectAgentCronJob-492:ctx-1fb6ecea) There is pending job or HA tasks working on the VM. vm id: 992, postpone power-change report by resetting power-change counters 2015-11-03 17:13:40,384 INFO [c.c.v.VirtualMachineManagerImpl] (DirectAgentCronJob-280:ctx-846ef4f0) There is pending job or HA tasks working on the VM. vm id: 992, postpone power-change report by resetting power-change counters 2015-11-03 17:13:49,799 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] (AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) Begin cleanup expired async-jobs 2015-11-03 17:13:49,825 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] (AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) End cleanup expired async-jobs 2015-11-03 17:13:55,688 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-13:ctx-06672650 job-165/job-166) Remove job-166 from job monitoring 2015-11-03 17:13:55,730 WARN [o.a.c.e.o.NetworkOrchestrator] (API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Failed to implement network Ntwk[208|Guest|15] elements and resources as a part of network restart due to com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is unreachable: Can't find all necessary running routers! at com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:202) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1103) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2546) at com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1891) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.apache.cloudstack.network.co
[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991500#comment-14991500 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-154027199 @koushik-das I don't think you are right, command serialisation uses LogLevel as well. Look at com.cloud.agent.transport.RequestTest and tell me if you agree. > listAPIs are taking too long to return results > -- > > Key: CLOUDSTACK-8485 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.1, 4.6.0 >Reporter: Sowmya Krishnan >Assignee: Koushik Das > Fix For: 4.6.0 > > > listAPIs are taking significantly longer than before (4.2.x) > I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K > Routers. Here are few results: > listVirtualMachines is taking > 25 sec to return with pagesize set to 50. > This is in comparison to 2 sec in earlier cases such as 4.2. > listVolumes with pagesize = 1000 took more than 10 mins and finally times out. > Further observations show that there are also lot of slow queries being > logged in catalina.out and in MySQL slow query logs. I am not sure if this > could be the reason for DB performance getting impacted in turn causing an > impact on listAPIs too. > Here's a sample of slow queries from catalina.out: > Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637759, statement-id: 3218312, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, > user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE > user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637843, statement-id: 3218311, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, > host.resource, host.fs_type, host.available, host.setup, host.resource_state, > host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, > host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, > host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, > host.mgmt_server_id, host.dom0_memory, host.version, host.created, > host.removed FROM host WHERE host.id = 345 AND host.removed IS NULL > Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 6458 ms, connection-id: 637623, statement-id: 3218243, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 > ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref INNER > JOIN host ON storage_pool_host_ref.host_id=host.id WHERE > storage_pool_host_ref.pool_id = 197 AND (host.status = 'Up' AND > host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 2402 ms, connection-id: 637754, statement-id: 3218371, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, > host.resource, host.fs_type, host.available, host.setup, host.resource_state, > host.hy
[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991495#comment-14991495 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user koushik-das commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-154025365 @DaanHoogland About the issue you pointed out in com.cloud.vm.VmWorkStart serialization. Nice find but these are already existing issues. They surely needs fixing but I feel a separate effort is better. What do you say? LogLevel can be safely used. If you look at the code there are 2 different GSON serializers - one for serialising the command that needs to be transmitted over the wire, and another is for logging purposes only. LogLevel is used in the latter one only. > listAPIs are taking too long to return results > -- > > Key: CLOUDSTACK-8485 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.1, 4.6.0 >Reporter: Sowmya Krishnan >Assignee: Koushik Das > Fix For: 4.6.0 > > > listAPIs are taking significantly longer than before (4.2.x) > I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K > Routers. Here are few results: > listVirtualMachines is taking > 25 sec to return with pagesize set to 50. > This is in comparison to 2 sec in earlier cases such as 4.2. > listVolumes with pagesize = 1000 took more than 10 mins and finally times out. > Further observations show that there are also lot of slow queries being > logged in catalina.out and in MySQL slow query logs. I am not sure if this > could be the reason for DB performance getting impacted in turn causing an > impact on listAPIs too. > Here's a sample of slow queries from catalina.out: > Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637759, statement-id: 3218312, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, > user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE > user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637843, statement-id: 3218311, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, > host.resource, host.fs_type, host.available, host.setup, host.resource_state, > host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, > host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, > host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, > host.mgmt_server_id, host.dom0_memory, host.version, host.created, > host.removed FROM host WHERE host.id = 345 AND host.removed IS NULL > Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 6458 ms, connection-id: 637623, statement-id: 3218243, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 > ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref INNER > JOIN host ON storage_pool_host_ref.host_id=host.id WHERE > storage_pool_host_ref.pool_id = 197 AND (host.status = 'Up' AND > host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 2402 ms, connection-id: 637754, statement-id: 3218371, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.publ
[jira] [Comment Edited] (CLOUDSTACK-8787) Network Update from Standalone VR offering to RVR offering is failing with Runtime Exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991474#comment-14991474
]
Deepthi Machiraju edited comment on CLOUDSTACK-8787 at 11/5/15 10:34 AM:
-
Hi [~remibergsma]
Following are the issues observed :
- Update from Standalone offering to RVR works .
- When updating from RVR offering to Standalone offering the VR comes up , but
it is observed that Public address isnt applied to the VR ,
mysql> select * from domain_router where id=61\G;
id: 61
element_id: 1
public_mac_address: NULL
public_ip_address: NULL
public_netmask: NULL
guest_netmask: NULL
guest_ip_address: NULL
is_redundant_router: 0
priority: NULL
redundant_state: UNKNOWN
stop_pending: 0
role: VIRTUAL_ROUTER
template_version: Cloudstack Release 4.7.0 Thu Sep 3 06:46:38 UTC 2015
scripts_version: 6c4e199c19601966d85f16e635a61db9
vpc_id: NULL
update_state: NULL
1 row in set (0.00 sec)
ERROR:
No query specified
mysql>
- Tried Restarting the Network , Following is the exception observed : which
mentions " Didn't support redundant virtual router without public network! "
2015-11-05 10:22:20,460 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-100:ctx-1865ce7b job-439) (logid:d49a00a8) Executing
AsyncJobVO {id:439, userId: 2, accountId: 2, instanceType: None, instanceId:
null, cmd: org.apache.cloudstack.api.command.user.network.RestartNetworkCmd,
cmdInfo:
{"id":"53a4b01a-69ca-44dd-a9a3-e1f5844c8af7","response":"json","cleanup":"false","ctxDetails":"{\"interface
com.cloud.network.Network\":\"53a4b01a-69ca-44dd-a9a3-e1f5844c8af7\"}","cmdEventType":"NETWORK.RESTART","ctxUserId":"2","httpmethod":"GET","_":"1446718968648","uuid":"53a4b01a-69ca-44dd-a9a3-e1f5844c8af7","ctxAccountId":"2","ctxStartEventId":"472"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 38442783480616, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2015-11-05 10:22:20,461 DEBUG [c.c.a.ApiServlet] (catalina-exec-12:ctx-2a7bd960
ctx-1ea2ff6d) (logid:c48527ad) ===END=== 10.252.192.72 -- GET
command=restartNetwork&id=53a4b01a-69ca-44dd-a9a3-e1f5844c8af7&cleanup=false&response=json&_=1446718968648
2015-11-05 10:22:20,481 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-100:ctx-1865ce7b job-439 ctx-07b20cc8) (logid:d49a00a8)
Restarting network 204...
2015-11-05 10:22:20,481 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-100:ctx-1865ce7b job-439 ctx-07b20cc8) (logid:d49a00a8) Skip
the shutting down of network id=204
2015-11-05 10:22:20,481 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-100:ctx-1865ce7b job-439 ctx-07b20cc8) (logid:d49a00a8)
Implementing the network Ntwk[204|Guest|22] elements and resources as a part of
network restart
2015-11-05 10:22:20,486 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-100:ctx-1865ce7b job-439 ctx-07b20cc8) (logid:d49a00a8)
Asking VirtualRouter to implemenet Ntwk[204|Guest|22]
2015-11-05 10:22:20,493 ERROR [o.c.n.r.d.RouterDeploymentDefinition]
(API-Job-Executor-100:ctx-1865ce7b job-439 ctx-07b20cc8) (logid:d49a00a8)
Didn't support redundant virtual router without public network!
2015-11-05 10:22:20,525 WARN [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-100:ctx-1865ce7b job-439 ctx-07b20cc8) (logid:d49a00a8)
Failed to implement network Ntwk[204|Guest|22] elements and resources as a part
of network restart due to
com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is
unreachable: Can't find all necessary running routers!
at
com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:228)
at
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1114)
at
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2603)
at
com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1903)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
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
org.apache.cloudstack.network.contrail.management.EventUtils$EventInt
[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991482#comment-14991482
]
ASF GitHub Bot commented on CLOUDSTACK-8485:
Github user koushik-das commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1021#discussion_r43997043
--- Diff: server/src/com/cloud/api/ApiResponseGsonHelper.java ---
@@ -71,4 +83,19 @@ public boolean shouldSkipField(FieldAttributes f) {
return false;
}
}
+
+private static class LogExclusionStrategy extends
ApiResponseExclusionStrategy implements ExclusionStrategy {
--- End diff --
The existing LoggingExlusionStrategy is for agent commands/workjob etc. But
it won't work for API responses. If you look at the code, exclusion strategy
for API response log depends on ApiResponseExclusionStrategy as well for
exclusion based on roles - user/admin.
> listAPIs are taking too long to return results
> --
>
> Key: CLOUDSTACK-8485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.5.1, 4.6.0
>Reporter: Sowmya Krishnan
>Assignee: Koushik Das
> Fix For: 4.6.0
>
>
> listAPIs are taking significantly longer than before (4.2.x)
> I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K
> Routers. Here are few results:
> listVirtualMachines is taking > 25 sec to return with pagesize set to 50.
> This is in comparison to 2 sec in earlier cases such as 4.2.
> listVolumes with pagesize = 1000 took more than 10 mins and finally times out.
> Further observations show that there are also lot of slow queries being
> logged in catalina.out and in MySQL slow query logs. I am not sure if this
> could be the reason for DB performance getting impacted in turn causing an
> impact on listAPIs too.
> Here's a sample of slow queries from catalina.out:
> Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 3305 ms, connection-id: 637759, statement-id: 3218312,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305
> ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name,
> user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE
> user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler
> Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 3305 ms, connection-id: 637843, statement-id: 3218311,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type,
> host.private_ip_address, host.private_mac_address, host.private_netmask,
> host.public_netmask, host.public_ip_address, host.public_mac_address,
> host.storage_ip_address, host.cluster_id, host.storage_netmask,
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2,
> host.storage_mac_address_2, host.hypervisor_type, host.proxy_port,
> host.resource, host.fs_type, host.available, host.setup, host.resource_state,
> host.hypervisor_version, host.update_count, host.uuid, host.data_center_id,
> host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram,
> host.parent, host.guid, host.capabilities, host.total_size, host.last_ping,
> host.mgmt_server_id, host.dom0_memory, host.version, host.created,
> host.removed FROM host WHERE host.id = 345 AND host.removed IS NULL
> Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 6458 ms, connection-id: 637623, statement-id: 3218243,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458
> ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref INNER
> JOIN host ON storage_pool_host_ref.host_id=host.id WHERE
> storage_pool_host_ref.pool_id = 197 AND (host.status = 'Up' AND
> host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler
> Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 2402 ms, connection-id: 637754, statement-id: 3218371,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402
> ms):SELECT host.id, host.disconnected, host.name, host.status, ho
[jira] [Assigned] (CLOUDSTACK-8787) Network Update from Standalone VR offering to RVR offering is failing with Runtime Exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kshitij Kansal reassigned CLOUDSTACK-8787: -- Assignee: Kshitij Kansal > Network Update from Standalone VR offering to RVR offering is failing with > Runtime Exception > > > Key: CLOUDSTACK-8787 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8787 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Deepthi Machiraju >Assignee: Kshitij Kansal > Fix For: 4.6.0 > > Attachments: management-server.zip, mysqlcloud.dmp > > > - Deploy a network with Standalone offering ID . > - Navigate to Network and update the offering from Standalone -> RVR. > Expected Result : > Network Update should be sucessful > Observation: > Network update is failing with the following below exception : " failed to > update network 637b4d16-a2ef-464c-a805-2375774a5730due to Failed to implement > network (with specified id) elements and resources as a part of network > update " > 015-08-31 10:59:13,044 DEBUG [c.c.v.VmWorkJobDispatcher] > (Work-Job-Executor-87:ctx-d2e23154 job-141/job-144) Done with run of VM work > job: com.cloud.vm.VmWorkStart for VM 33, job origin: 141 > 2015-08-31 10:59:13,044 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (Work-Job-Executor-87:ctx-d2e23154 job-141/job-144) Done executing > com.cloud.vm.VmWorkStart for job-144 > 2015-08-31 10:59:13,049 WARN [c.c.n.NetworkServiceImpl] > (API-Job-Executor-47:ctx-14794ea0 job-141 ctx-70358d9a) Failed to implement > network Ntwk[206|Guest|18] elements and resources as a part of network update > due to > com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is > unreachable: Can't find all necessary running routers! > at > com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:227) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1113) > at > com.cloud.network.NetworkServiceImpl.updateGuestNetwork(NetworkServiceImpl.java:2354) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > 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 > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) > 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 $Proxy161.updateGuestNetwork(Unknown Source) > at > org.apache.cloudstack.api.command.admin.network.UpdateNetworkCmdByAdmin.execute(UpdateNetworkCmdByAdmin.java:51) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537) > 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(Managed
[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991479#comment-14991479 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user koushik-das commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1021#discussion_r43996820 --- Diff: server/src/com/cloud/api/ApiResponseGsonHelper.java --- @@ -27,30 +29,40 @@ import com.google.gson.GsonBuilder; /** - * The ApiResonseGsonHelper is different from ApiGsonHelper - it registeres one more adapter for String type required for api response encoding + * The ApiResonseGsonHelper is different from ApiGsonHelper - it registers one more adapter for String type required for api response encoding --- End diff -- I have to read more on the gson changes you are referring to. But I think we shouldn't mix multiple things with this. The primary purpose of this PR is to fix the perf. issue in list API responses. There may be some rework if gson is upgraded but it is better to do that when gson upgrade work is done. > listAPIs are taking too long to return results > -- > > Key: CLOUDSTACK-8485 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.1, 4.6.0 >Reporter: Sowmya Krishnan >Assignee: Koushik Das > Fix For: 4.6.0 > > > listAPIs are taking significantly longer than before (4.2.x) > I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K > Routers. Here are few results: > listVirtualMachines is taking > 25 sec to return with pagesize set to 50. > This is in comparison to 2 sec in earlier cases such as 4.2. > listVolumes with pagesize = 1000 took more than 10 mins and finally times out. > Further observations show that there are also lot of slow queries being > logged in catalina.out and in MySQL slow query logs. I am not sure if this > could be the reason for DB performance getting impacted in turn causing an > impact on listAPIs too. > Here's a sample of slow queries from catalina.out: > Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637759, statement-id: 3218312, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, > user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE > user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637843, statement-id: 3218311, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, > host.resource, host.fs_type, host.available, host.setup, host.resource_state, > host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, > host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, > host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, > host.mgmt_server_id, host.dom0_memory, host.version, host.created, > host.removed FROM host WHERE host.id = 345 AND host.removed IS NULL > Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 6458 ms, connection-id: 637623, statement-id: 3218243, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 > ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref INNER > JOIN host ON storage_pool_host_ref.host_id=host.id WHERE > storage_pool_host_ref.pool_id = 197 AND (host.status = 'Up' AND > host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 2402 ms, connection-id: 637754,
[jira] [Commented] (CLOUDSTACK-8787) Network Update from Standalone VR offering to RVR offering is failing with Runtime Exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991474#comment-14991474
]
Deepthi Machiraju commented on CLOUDSTACK-8787:
---
Hi [~remibergsma]
Following are the issues observed :
- Update from Standalone offering to RVR works .
- When updating from RVR offering to Standalone offering the VR comes up , but
it is observed that Public address isnt applied to the VR ,
mysql> select * from domain_router where id=61\G;
id: 61
element_id: 1
public_mac_address: NULL
public_ip_address: NULL
public_netmask: NULL
guest_netmask: NULL
guest_ip_address: NULL
is_redundant_router: 0
priority: NULL
redundant_state: UNKNOWN
stop_pending: 0
role: VIRTUAL_ROUTER
template_version: Cloudstack Release 4.7.0 Thu Sep 3 06:46:38 UTC 2015
scripts_version: 6c4e199c19601966d85f16e635a61db9
vpc_id: NULL
update_state: NULL
1 row in set (0.00 sec)
ERROR:
No query specified
mysql>
- Tried Restarting the Network , Following is the exception observed :
2015-11-05 10:22:20,460 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-100:ctx-1865ce7b job-439) (logid:d49a00a8) Executing
AsyncJobVO {id:439, userId: 2, accountId: 2, instanceType: None, instanceId:
null, cmd: org.apache.cloudstack.api.command.user.network.RestartNetworkCmd,
cmdInfo:
{"id":"53a4b01a-69ca-44dd-a9a3-e1f5844c8af7","response":"json","cleanup":"false","ctxDetails":"{\"interface
com.cloud.network.Network\":\"53a4b01a-69ca-44dd-a9a3-e1f5844c8af7\"}","cmdEventType":"NETWORK.RESTART","ctxUserId":"2","httpmethod":"GET","_":"1446718968648","uuid":"53a4b01a-69ca-44dd-a9a3-e1f5844c8af7","ctxAccountId":"2","ctxStartEventId":"472"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 38442783480616, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2015-11-05 10:22:20,461 DEBUG [c.c.a.ApiServlet] (catalina-exec-12:ctx-2a7bd960
ctx-1ea2ff6d) (logid:c48527ad) ===END=== 10.252.192.72 -- GET
command=restartNetwork&id=53a4b01a-69ca-44dd-a9a3-e1f5844c8af7&cleanup=false&response=json&_=1446718968648
2015-11-05 10:22:20,481 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-100:ctx-1865ce7b job-439 ctx-07b20cc8) (logid:d49a00a8)
Restarting network 204...
2015-11-05 10:22:20,481 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-100:ctx-1865ce7b job-439 ctx-07b20cc8) (logid:d49a00a8) Skip
the shutting down of network id=204
2015-11-05 10:22:20,481 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-100:ctx-1865ce7b job-439 ctx-07b20cc8) (logid:d49a00a8)
Implementing the network Ntwk[204|Guest|22] elements and resources as a part of
network restart
2015-11-05 10:22:20,486 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-100:ctx-1865ce7b job-439 ctx-07b20cc8) (logid:d49a00a8)
Asking VirtualRouter to implemenet Ntwk[204|Guest|22]
2015-11-05 10:22:20,493 ERROR [o.c.n.r.d.RouterDeploymentDefinition]
(API-Job-Executor-100:ctx-1865ce7b job-439 ctx-07b20cc8) (logid:d49a00a8)
Didn't support redundant virtual router without public network!
2015-11-05 10:22:20,525 WARN [o.a.c.e.o.NetworkOrchestrator]
(API-Job-Executor-100:ctx-1865ce7b job-439 ctx-07b20cc8) (logid:d49a00a8)
Failed to implement network Ntwk[204|Guest|22] elements and resources as a part
of network restart due to
com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is
unreachable: Can't find all necessary running routers!
at
com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:228)
at
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1114)
at
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2603)
at
com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1903)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
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
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodIn
[jira] [Commented] (CLOUDSTACK-9037) interface prefixes are not really prefixes in libvirtcomputeresource
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991471#comment-14991471 ] ASF GitHub Bot commented on CLOUDSTACK-9037: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1035#issuecomment-154019836 tested. LGTM > interface prefixes are not really prefixes in libvirtcomputeresource > > > Key: CLOUDSTACK-9037 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9037 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > the patterns that are matched don't contain "^" which can lead to strange > matches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991470#comment-14991470 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user koushik-das commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1021#discussion_r43996309 --- Diff: api/src/org/apache/cloudstack/api/response/UserVmResponse.java --- @@ -256,6 +259,7 @@ @SerializedName(ApiConstants.SSH_KEYPAIR) @Param(description = "ssh key-pair") +@LogLevel(Log4jLevel.Off) --- End diff -- thought its the actual data, will change > listAPIs are taking too long to return results > -- > > Key: CLOUDSTACK-8485 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.1, 4.6.0 >Reporter: Sowmya Krishnan >Assignee: Koushik Das > Fix For: 4.6.0 > > > listAPIs are taking significantly longer than before (4.2.x) > I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K > Routers. Here are few results: > listVirtualMachines is taking > 25 sec to return with pagesize set to 50. > This is in comparison to 2 sec in earlier cases such as 4.2. > listVolumes with pagesize = 1000 took more than 10 mins and finally times out. > Further observations show that there are also lot of slow queries being > logged in catalina.out and in MySQL slow query logs. I am not sure if this > could be the reason for DB performance getting impacted in turn causing an > impact on listAPIs too. > Here's a sample of slow queries from catalina.out: > Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637759, statement-id: 3218312, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, > user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE > user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637843, statement-id: 3218311, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, > host.resource, host.fs_type, host.available, host.setup, host.resource_state, > host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, > host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, > host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, > host.mgmt_server_id, host.dom0_memory, host.version, host.created, > host.removed FROM host WHERE host.id = 345 AND host.removed IS NULL > Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 6458 ms, connection-id: 637623, statement-id: 3218243, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 > ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref INNER > JOIN host ON storage_pool_host_ref.host_id=host.id WHERE > storage_pool_host_ref.pool_id = 197 AND (host.status = 'Up' AND > host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 2402 ms, connection-id: 637754, statement-id: 3218371, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host
[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991469#comment-14991469 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user koushik-das commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1021#discussion_r43996196 --- Diff: api/src/org/apache/cloudstack/api/response/SslCertResponse.java --- @@ -38,6 +40,7 @@ @SerializedName(ApiConstants.CERTIFICATE) @Param(description = "certificate") +@LogLevel(Log4jLevel.Off) --- End diff -- I suppressed cert. related data from getting logged. But you are right they are not sensitive. > listAPIs are taking too long to return results > -- > > Key: CLOUDSTACK-8485 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.1, 4.6.0 >Reporter: Sowmya Krishnan >Assignee: Koushik Das > Fix For: 4.6.0 > > > listAPIs are taking significantly longer than before (4.2.x) > I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K > Routers. Here are few results: > listVirtualMachines is taking > 25 sec to return with pagesize set to 50. > This is in comparison to 2 sec in earlier cases such as 4.2. > listVolumes with pagesize = 1000 took more than 10 mins and finally times out. > Further observations show that there are also lot of slow queries being > logged in catalina.out and in MySQL slow query logs. I am not sure if this > could be the reason for DB performance getting impacted in turn causing an > impact on listAPIs too. > Here's a sample of slow queries from catalina.out: > Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637759, statement-id: 3218312, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, > user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE > user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637843, statement-id: 3218311, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, > host.resource, host.fs_type, host.available, host.setup, host.resource_state, > host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, > host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, > host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, > host.mgmt_server_id, host.dom0_memory, host.version, host.created, > host.removed FROM host WHERE host.id = 345 AND host.removed IS NULL > Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 6458 ms, connection-id: 637623, statement-id: 3218243, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 > ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref INNER > JOIN host ON storage_pool_host_ref.host_id=host.id WHERE > storage_pool_host_ref.pool_id = 197 AND (host.status = 'Up' AND > host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 2402 ms, connection-id: 637754, statement-id: 3218371, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host
[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991465#comment-14991465
]
ASF GitHub Bot commented on CLOUDSTACK-8485:
Github user koushik-das commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1021#discussion_r43996031
--- Diff:
api/src/org/apache/cloudstack/api/response/SSHKeyPairResponse.java ---
@@ -40,6 +42,7 @@
@SerializedName("fingerprint")
@Param(description = "Fingerprint of the public key")
+@LogLevel(Log4jLevel.Off)
--- End diff --
will change
> listAPIs are taking too long to return results
> --
>
> Key: CLOUDSTACK-8485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.5.1, 4.6.0
>Reporter: Sowmya Krishnan
>Assignee: Koushik Das
> Fix For: 4.6.0
>
>
> listAPIs are taking significantly longer than before (4.2.x)
> I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K
> Routers. Here are few results:
> listVirtualMachines is taking > 25 sec to return with pagesize set to 50.
> This is in comparison to 2 sec in earlier cases such as 4.2.
> listVolumes with pagesize = 1000 took more than 10 mins and finally times out.
> Further observations show that there are also lot of slow queries being
> logged in catalina.out and in MySQL slow query logs. I am not sure if this
> could be the reason for DB performance getting impacted in turn causing an
> impact on listAPIs too.
> Here's a sample of slow queries from catalina.out:
> Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 3305 ms, connection-id: 637759, statement-id: 3218312,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305
> ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name,
> user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE
> user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler
> Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 3305 ms, connection-id: 637843, statement-id: 3218311,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type,
> host.private_ip_address, host.private_mac_address, host.private_netmask,
> host.public_netmask, host.public_ip_address, host.public_mac_address,
> host.storage_ip_address, host.cluster_id, host.storage_netmask,
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2,
> host.storage_mac_address_2, host.hypervisor_type, host.proxy_port,
> host.resource, host.fs_type, host.available, host.setup, host.resource_state,
> host.hypervisor_version, host.update_count, host.uuid, host.data_center_id,
> host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram,
> host.parent, host.guid, host.capabilities, host.total_size, host.last_ping,
> host.mgmt_server_id, host.dom0_memory, host.version, host.created,
> host.removed FROM host WHERE host.id = 345 AND host.removed IS NULL
> Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 6458 ms, connection-id: 637623, statement-id: 3218243,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458
> ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref INNER
> JOIN host ON storage_pool_host_ref.host_id=host.id WHERE
> storage_pool_host_ref.pool_id = 197 AND (host.status = 'Up' AND
> host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler
> Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 2402 ms, connection-id: 637754, statement-id: 3218371,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type,
> host.private_ip_address, host.private_mac_address, host.private_netmask,
> host.public_netmask, host.public_ip_address, host.public_mac_address,
> host.storage_ip_address, host.cluster_id, host.storage_netmask,
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2,
> host.storage_mac_address
[jira] [Commented] (CLOUDSTACK-9037) interface prefixes are not really prefixes in libvirtcomputeresource
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991430#comment-14991430 ] ASF GitHub Bot commented on CLOUDSTACK-9037: GitHub user DaanHoogland opened a pull request: https://github.com/apache/cloudstack/pull/1035 CLOUDSTACK-9037 patterns can be more elaborate then prefixes. little fix to make sure for instance "eth" is not regarded as interface when it is part of "methamfetamine" You can merge this pull request into a Git repository by running: $ git pull https://github.com/DaanHoogland/cloudstack CLOUDSTACK-9037 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1035.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1035 commit 57ea4506e1f84174a8fb53e70d4901f2a4bb7c24 Author: Daan Hoogland Date: 2015-11-05T09:49:17Z CLOUDSTACK-9037 patterns can be more elaborate then prefixes. > interface prefixes are not really prefixes in libvirtcomputeresource > > > Key: CLOUDSTACK-9037 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9037 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > the patterns that are matched don't contain "^" which can lead to strange > matches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9037) interface prefixes are not really prefixes in libvirtcomputeresource
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991403#comment-14991403 ] Daan Hoogland commented on CLOUDSTACK-9037: --- prepending the "^" and renaming the array name to make sure it is seen as a list of patterns instead of prefixes. > interface prefixes are not really prefixes in libvirtcomputeresource > > > Key: CLOUDSTACK-9037 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9037 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > the patterns that are matched don't contain "^" which can lead to strange > matches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9037) interface prefixes are not really prefixes in libvirtcomputeresource
Daan Hoogland created CLOUDSTACK-9037: - Summary: interface prefixes are not really prefixes in libvirtcomputeresource Key: CLOUDSTACK-9037 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9037 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Reporter: Daan Hoogland Assignee: Daan Hoogland the patterns that are matched don't contain "^" which can lead to strange matches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991383#comment-14991383 ] Wilder Rodrigues commented on CLOUDSTACK-9035: -- Changed the issue to Critical until We actually know if there is a way to reset the passwd on the backup router or not. Cheers, Wilder > Password file is stored only with Master when we Reset Password on the VM. > -- > > Key: CLOUDSTACK-9035 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Wilder Rodrigues >Priority: Critical > Fix For: 4.6.0 > > > we send the save password command to both the VRs in a rvr enabled network, > But the password gets saved only in the master VR. This happens because the > password server is not running in the backup. > Because of this if someone resets the password of a VM and starts it when the > backup becomes master. Then the password of the user VM will not change, > because the save password command was not successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wilder Rodrigues updated CLOUDSTACK-9035: - Priority: Critical (was: Blocker) > Password file is stored only with Master when we Reset Password on the VM. > -- > > Key: CLOUDSTACK-9035 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Wilder Rodrigues >Priority: Critical > Fix For: 4.6.0 > > > we send the save password command to both the VRs in a rvr enabled network, > But the password gets saved only in the master VR. This happens because the > password server is not running in the backup. > Because of this if someone resets the password of a VM and starts it when the > backup becomes master. Then the password of the user VM will not change, > because the save password command was not successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wilder Rodrigues reassigned CLOUDSTACK-9035: Assignee: Wilder Rodrigues > Password file is stored only with Master when we Reset Password on the VM. > -- > > Key: CLOUDSTACK-9035 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > we send the save password command to both the VRs in a rvr enabled network, > But the password gets saved only in the master VR. This happens because the > password server is not running in the backup. > Because of this if someone resets the password of a VM and starts it when the > backup becomes master. Then the password of the user VM will not change, > because the save password command was not successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7375) [UI] RBD not available under list of protocols for primary storage during zone creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Amorim Faria updated CLOUDSTACK-7375: --- Affects Version/s: 4.6.0 > [UI] RBD not available under list of protocols for primary storage during > zone creation > --- > > Key: CLOUDSTACK-7375 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7375 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0, 4.6.0 >Reporter: Pavan Kumar Bandarupally > Fix For: Future > > Attachments: screenshot-1.jpg > > > Currently cloudstack supports CEPH storage as primary store without a > requirement for another NFS store before adding CEPH storage. But during zone > creation, we don't see RBD under protocol list for primary storage addition > wizard. > Please see attached image. > Expected: > - > There should be RBD protocol so that user can add a CEPH primary store during > zone creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9036) IPV6 CIDR not recognized (Parser BUG)
Franz Skale created CLOUDSTACK-9036: --- Summary: IPV6 CIDR not recognized (Parser BUG) Key: CLOUDSTACK-9036 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9036 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.6.0 Environment: XEN Server 6.5 SP1 (Hosts) Cloudstack 4.6 (SNAPSHOT) Management Server (Ubuntu 14.04 Trusty) Reporter: Franz Skale When creating a new Guest Network with IPV6 enabled VLAN, the IPV6 CIDR will not be recognized. There seems to be a ipv6 CIDR parser error: Example: IPV6 GW: fde4:101:a01::1 IPV6 CIDR: fde4:101:a01:0:0:0:0:0/64 (Error: The specified IPv6 CIDR is invalid) IPV6 Start: fde4:101:a01::100 IPV6 End: fde4:101:a01::1aa If i try to use the IPV6 CIDR fde4:101:a01:0:0:0:0:0/6 (without the 4 at then for a 64 bit cidr) the selection will be accepted but of course after save the error occurs, that the cidr is wrong. Best regds. Franz -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6797) volume resize should not be allowed for detached volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991297#comment-14991297 ] Wei Zhou commented on CLOUDSTACK-6797: -- [~shadowsor]] I agree with Marcus. We should not disallow the volume resize of detached volumes. it works most of time. A better way might be checking the allocate capacity of pool when it is created on primary storage (from Allocated to Ready), and checking the allocate capacity of cluster (where the vm is) when it is attached. > volume resize should not be allowed for detached volumes > > > Key: CLOUDSTACK-6797 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6797 > 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, 4.4.0 >Reporter: prashant kumar mishra >Assignee: Marcus Sorensen >Priority: Critical > Fix For: Future > > Attachments: Logs_db.rar, screenshot-1.jpg, screenshot-2.jpg > > > =>since resize space is counted in allocated space even though it cant be > attach to VM , other storage operation will fail because threshold value > If resize is allowed in volume detach > == > 1-since there is no check for how much can be increased , suppose user has > resized it to 1000GB > 2-when user try to attach volume to vm it will fail since available space is > not sufficient . > 3-even though user is not able to use the resized volume ,CS will count > 1000GB in allocated storage . > 4-Dash will show allocated percentage >100% > 5-Because threshold values , we cant perform any operation to that PS > If resize is allowed online ( volume Attach) state it will fail in first > place and will not cause any problem -- This message was sent by Atlassian JIRA (v6.3.4#6332)
