[jira] [Commented] (CLOUDSTACK-9064) Can't create multiple "Guest Networks" with same VLAN ID in the same zone on different "Physical Networks"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023934#comment-15023934 ] Abhinandan Prateek commented on CLOUDSTACK-9064: The users should be able to create multiple Guest Shared Networks in same Vlan ID, same Physical Network and same network, just with a different IP ranges. > Can't create multiple "Guest Networks" with same VLAN ID in the same zone on > different "Physical Networks" > --- > > Key: CLOUDSTACK-9064 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9064 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek >Priority: Critical > > We can't create multiple "Guest Networks" with same VLAN ID in the same zone > on different "Physical Networks". > I get this message then I try: > There is a isolated/shared network with vlan id: already exists in > zone > We had added that feature and it was working in 4.1+, but > apparently there is a regression. There's no reason the same VLAN ids can't > be reused on different physical networks > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3CCALFpzo5X169uj-3e4Jb-BsJ%2BXabSUyFJfMULKFNoBP0pP_geLg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9069) Newly added project is not showing in the drop down until the browser is refreshed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023909#comment-15023909 ] ASF GitHub Bot commented on CLOUDSTACK-9069: Github user nitin-maharana commented on the pull request: https://github.com/apache/cloudstack/pull/1077#issuecomment-159181731 @rafaelweingartner This PR will merge with current master. and #1082 Will merge in branch 4.6. Thanks. > Newly added project is not showing in the drop down until the browser is > refreshed. > --- > > Key: CLOUDSTACK-9069 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9069 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > Steps to reproduce: > 1.Login as admin and navigate to Projects page. > 2.Add one project and navigate to Dashboard. > 3.Check for newly added project in Project drop down. > Actual behaviour: > New project is showing in drop down only after refreshing the browser. > Expected behaviour: > New project should be shown in drop down without refreshing the browser also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9069) Newly added project is not showing in the drop down until the browser is refreshed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023906#comment-15023906 ] ASF GitHub Bot commented on CLOUDSTACK-9069: Github user nitin-maharana commented on the pull request: https://github.com/apache/cloudstack/pull/1082#issuecomment-159181399 @rafaelweingartner This is happening in 4.5. I checked with this master. > Newly added project is not showing in the drop down until the browser is > refreshed. > --- > > Key: CLOUDSTACK-9069 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9069 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > Steps to reproduce: > 1.Login as admin and navigate to Projects page. > 2.Add one project and navigate to Dashboard. > 3.Check for newly added project in Project drop down. > Actual behaviour: > New project is showing in drop down only after refreshing the browser. > Expected behaviour: > New project should be shown in drop down without refreshing the browser also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9061) cannot deploy Instance when using Swift as Secondary Storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023900#comment-15023900 ] ASF GitHub Bot commented on CLOUDSTACK-9061: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1112#issuecomment-159179498 Pinging @pdion891 to have a look. > cannot deploy Instance when using Swift as Secondary Storage > > > Key: CLOUDSTACK-9061 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9061 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Secondary Storage >Affects Versions: 4.5.2, 4.6.0 >Reporter: Pierre-Luc Dion > > When using Swift as Secondary Storage, new Instance cannot be created. > Uploading new template work and end up correctly into swift. but creating > VM's from this new template fail. > Seams that the SSVM fail do create the cache template into the Primary > storage. Observer on XenServer 6.2 with CloudStack 4.5.2 and 4.6.0rc1 > This feature work well in 4.4.x. -- 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=15023895#comment-15023895 ] ASF GitHub Bot commented on CLOUDSTACK-9037: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1035#issuecomment-159179464 [1035.network.results.txt](https://github.com/apache/cloudstack/files/42442/1035.network.results.txt) [1035.vpc.results.txt](https://github.com/apache/cloudstack/files/42443/1035.vpc.results.txt) @remibergsma @karuturi simple fix, can you merge? > 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-9077) injectkeys.sh doesn't work on CentOS7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023588#comment-15023588 ] ASF GitHub Bot commented on CLOUDSTACK-9077: Github user pdion891 commented on the pull request: https://github.com/apache/cloudstack/pull/1109#issuecomment-159130294 @remibergsma can you update this PR with following update: It still need to look for ``/dev/loop0`` inside docker to know if it can update the sshkey at the template creation process. right after line 87 ``` # if running into Docker as unprivileges, skip ssh verification as iso cannot be mounted due to missing loop device. if [ -f /.dockerinit ]; then if [ -e /dev/loop0 ]; then # it's a docker instance with privileges. inject_into_iso systemvm.iso $newpubkey [ $? -ne 0 ] && exit 5 copy_priv_key $newprivkey else # this mean it's a docker instance, ssh key cannot be verify. echo "We run inside Docker, skipping ssh key insertion in systemvm.iso" fi else inject_into_iso systemvm.iso $newpubkey [ $? -ne 0 ] && exit 5 copy_priv_key $newprivkey fi ``` Thanks > injectkeys.sh doesn't work on CentOS7 > - > > Key: CLOUDSTACK-9077 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9077 > 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 >Reporter: Remi Bergsma >Priority: Critical > > Regression from: > https://github.com/apache/cloudstack/commit/3381154fafb7fa4f0a61d538f7c2550e48247787 > CentOS7 doesn't have /dev/loop0 so it fails. Removing the check makes it work > again. > ``` > 2015-11-20 21:51:16,145 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Executing: /bin/bash > /var/lib/tomcat/webapps/client/WEB-INF/classes/scripts/vm/systemvm/injectkeys.sh > /usr/share/tomc > at5/.ssh/id_rsa.pub /usr/share/tomcat5/.ssh/id_rsa > /var/lib/tomcat/webapps/client/WEB-INF/classes/vms/systemvm.iso > 2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Execution is successful. > 2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) No loop device found, skipping ssh key insertion > in systemvm.iso > 2015-11-20 21:51:16,162 INFO [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Injected public and private keys into systemvm > iso with result : null > ``` > Pinging [~pdion] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9054) countIp6InRange(final String ip6Range) does not handle open range
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023570#comment-15023570 ] ASF GitHub Bot commented on CLOUDSTACK-9054: Github user rafaelweingartner commented on the pull request: https://github.com/apache/cloudstack/pull/1060#issuecomment-159127168 I would rather use Java 1.8. We are already migrating to Java 8, right? > countIp6InRange(final String ip6Range) does not handle open range > - > > Key: CLOUDSTACK-9054 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9054 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > in case of '-1::0' or "0::0-" errors are thrown while the meaning of the > range is clear > In the testcase for this method an exception is thrown because of this: > 2015-11-11 10:20:57,997 ERROR [utils.net.NetUtils] (main:) Failed to convert > a string to an IPv6 address > java.lang.IllegalArgumentException: can not parse [] > at > com.googlecode.ipv6.IPv6Address.tryParseStringArrayIntoLongArray(IPv6Address.java:94) > at com.googlecode.ipv6.IPv6Address.fromString(IPv6Address.java:80) > at com.cloud.utils.net.NetUtils.countIp6InRange(NetUtils.java:1332) > at > com.cloud.utils.net.NetUtilsTest.testCountIp6InRangeWithNullStart(NetUtilsTest.java:153) > 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9069) Newly added project is not showing in the drop down until the browser is refreshed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023566#comment-15023566 ] ASF GitHub Bot commented on CLOUDSTACK-9069: Github user rafaelweingartner commented on the pull request: https://github.com/apache/cloudstack/pull/1077#issuecomment-159125686 Isn't this PR the same as #1082? > Newly added project is not showing in the drop down until the browser is > refreshed. > --- > > Key: CLOUDSTACK-9069 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9069 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > Steps to reproduce: > 1.Login as admin and navigate to Projects page. > 2.Add one project and navigate to Dashboard. > 3.Check for newly added project in Project drop down. > Actual behaviour: > New project is showing in drop down only after refreshing the browser. > Expected behaviour: > New project should be shown in drop down without refreshing the browser also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9069) Newly added project is not showing in the drop down until the browser is refreshed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023564#comment-15023564 ] ASF GitHub Bot commented on CLOUDSTACK-9069: Github user rafaelweingartner commented on the pull request: https://github.com/apache/cloudstack/pull/1082#issuecomment-159125197 In which version is this problem happening? I tested on CS 4.3.2 and it is working. I used both Chrome and Firefox. > Newly added project is not showing in the drop down until the browser is > refreshed. > --- > > Key: CLOUDSTACK-9069 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9069 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > Steps to reproduce: > 1.Login as admin and navigate to Projects page. > 2.Add one project and navigate to Dashboard. > 3.Check for newly added project in Project drop down. > Actual behaviour: > New project is showing in drop down only after refreshing the browser. > Expected behaviour: > New project should be shown in drop down without refreshing the browser also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9061) cannot deploy Instance when using Swift as Secondary Storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022788#comment-15022788 ] Syed Ahmed commented on CLOUDSTACK-9061: https://github.com/apache/cloudstack/pull/1112 > cannot deploy Instance when using Swift as Secondary Storage > > > Key: CLOUDSTACK-9061 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9061 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Secondary Storage >Affects Versions: 4.5.2, 4.6.0 >Reporter: Pierre-Luc Dion > > When using Swift as Secondary Storage, new Instance cannot be created. > Uploading new template work and end up correctly into swift. but creating > VM's from this new template fail. > Seams that the SSVM fail do create the cache template into the Primary > storage. Observer on XenServer 6.2 with CloudStack 4.5.2 and 4.6.0rc1 > This feature work well in 4.4.x. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9061) cannot deploy Instance when using Swift as Secondary Storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022786#comment-15022786 ] ASF GitHub Bot commented on CLOUDSTACK-9061: GitHub user syed opened a pull request: https://github.com/apache/cloudstack/pull/1112 Fix Instance creation with swift as Secondary Storage [CLOUDSTACK-9061] Swift is currently broken when used as Secondary storage. This fix does the right thing when creating directories on the NFS staging server. We should think of a better solution as this should have been common code path between S3 and Swift. We should also make the "Object Storage as Secondary Storage" interface generic so that we can add other object stores too. -Syed You can merge this pull request into a Git repository by running: $ git pull https://github.com/syed/cloudstack master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1112.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 #1112 commit ecc93bbded2cde8f1a0fccd8ac86b8079a85db09 Author: Syed Date: 2015-11-23T19:14:14Z Fix Instance creation with swift as Secondary Storage [CLOUDSTACK-9061] > cannot deploy Instance when using Swift as Secondary Storage > > > Key: CLOUDSTACK-9061 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9061 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Secondary Storage >Affects Versions: 4.5.2, 4.6.0 >Reporter: Pierre-Luc Dion > > When using Swift as Secondary Storage, new Instance cannot be created. > Uploading new template work and end up correctly into swift. but creating > VM's from this new template fail. > Seams that the SSVM fail do create the cache template into the Primary > storage. Observer on XenServer 6.2 with CloudStack 4.5.2 and 4.6.0rc1 > This feature work well in 4.4.x. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022574#comment-15022574 ] ASF GitHub Bot commented on CLOUDSTACK-9074: Github user nvazquez commented on the pull request: https://github.com/apache/cloudstack/pull/1094#issuecomment-159007416 Thanks @remibergsma ! > Support shared networking in NiciraNVP Plugin > - > > Key: CLOUDSTACK-9074 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Nicolas Vazquez > Fix For: 4.7.0 > > > h3. Introduction > Currently NiciraNVP plugin supports only Isolated networking. In this mode of > operations networks are assigned to individual Cloudstack accounts and on NSX > side are completely isolated on the L3 level. Many use cases especially in > corporate environment call for shared networking mode support. In some > circumstances there also may be a need to translate shared NSX network over > to a physical VLAN via L2 NSX gateway. > Features that will be introduced to support Cloudstack shared networks in two > modes of NiciraNVP plugin: > * Shared networks mapped to a physical VLAN with L2 NSX gateway > * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will > be supported. > h3. Features > h4. 1) Shared networking model support > # Support native Cloudstack shared network in NiciraNVP plugin. > # Current code that implements isolated networking mode support will stay > intact. > # Designate network service offering by configuring VirtualNetworking > provider with NiciraNVP. > # Static/Source NAT is not used and ignored if defined in the network > offering. > # Nicira_vvp_router_map table will support non-unique logical routers to > implement L3 NSX routing domains where multiple Cloudstack networks are > attached to the same logical router. > # Shared network with NSX based Virtual networking will go through the > following states: > ## Allocated > ## Implementing > ## Implemented > ## Destroy > h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network > # Optional L2gatewayserviceuuid parameter for NiciraNVP controller > # VLAN ID of a Shared network represents VLAN to pass through L2 gateway > similar to native Cloudstack shared networking > # NSX workflow for network allocation > ## Check if l2gatewayservice defined > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_doamin > ### Vlan://vlan_id as broadcast_uri > ## Create record in VLAN table > # NSX workflow for network implementation > ## Check if l2gatewayservice defined and valid > ## Create logical switch > ## Map logical switch to L2gateway service assigning shared network VLAN ID > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 3) Support NSX L3 multiple routing domains > # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a > particular routing domain. We will support UUID style notation for VLAN ID. > l3gatewayservice option is not used in shared networking > # It is assumed that if connectivity to the physical networking is required > then logical router is configured and connected to the physical network in > advance. NiciraNVP plugin will not perform any task beyond basic connectivity > to the logical router > # Support NSX L3 multiple routing domains > # NSX workflow for network allocation > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_domain > ### NULL as broadcast_uri > ## Create record in VLAN table > ## Create record in nicira_nvp_router_map table > # NSX workflow for network implementation > ## Check if logical router exists on NSX side which UUID matches the one > defined during shared network creation. This mode is activated if VLAN ID > supplied in UUID style notation > ## Create logical switch > ## Attach logical switch to the logical router > ## Assign shared network default gateway to the inside port of the logical > router > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 4) API Changes > # Existing API addNiciraNvpDevices will be updated > ## Adding 1 new optional parameter – l2gatewayserviceuuid > ## Adding 1 new response tag – l2gatewayserviceuuid > # Existing API listNiciraNvpDevices will be updated > ## Adding 1 new response tag – l2gatewayserviceuuid > # Existing API listNics will be updated > ## Adding 2 new optional response tag – nsxlogicalswitch, nsxlogicalswitchport -- This message was sent b
[jira] [Commented] (CLOUDSTACK-8816) rabbitMQ: generated events have wrong or missing uuids
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022522#comment-15022522
]
ASF GitHub Bot commented on CLOUDSTACK-8816:
GitHub user ProjectMoon opened a pull request:
https://github.com/apache/cloudstack/pull/
Fix event UUIDS missing on event bus
The fixing of CLOUDSTACK-8816 introduced a regression that removed the
first class entities in the event bus description property. This is because
everything was changed to use the Class as a key... Everything but the
populateFirstClassEntities method in ActionEventUtils.
This commit tries to load the class key instead of the String key, which
re-enables the populateFirstClassEntities method.
Likely this was not caught because of the trace exception handling... maybe
some better logging/unit tests would be good for this PR.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/greenqloud/cloudstack pr-eventbus-entity-uuids
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/.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 #
commit a528c396d718f0ea6eecbdda7c23c8d7f670d99c
Author: jeff
Date: 2015-11-23T17:15:57Z
Fix event UUIDS missing on event bus
The fixing of CLOUDSTACK-8816 introduced a regression that removed the
first class entities in the event bus description property. This is
because everything was changed to use the Class as a key... Everything
but the populateFirstClassEntities method in ActionEventUtils.
> rabbitMQ: generated events have wrong or missing uuids
> --
>
> Key: CLOUDSTACK-8816
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8816
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.2, 4.4.4, 4.5.2, 4.6.0
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>Priority: Critical
>
> For many events, entity uuids are missing. One such example is below.
> (updated in the comments with events before and after the changes)
> 1. create an account ppp
> 2,create few users under ppp account
> 3.delete the "ppp" account
> 4.check the rabbit mq for generated events
> actual result:
> Therecieved event has admin user uuid instead of deleted account uuid
> The server reported 0 messages remaining.
> Exchange cloudstack-events
> Routing Key management-server.AsyncJobEvent.complete.Account.*
> Redelivered ●
> Properties
> priority: 0
> delivery_mode:2
> content_type: text/plain
> Payload 885 bytes Encoding: string
> {"cmdInfo":"{\"id\":\"d08d73a5-b577-4082-a959-114b433979f1\",\"response\":\"json\",\"sessionkey\":\"bYp8fdaTPgTYLtuVlSPxnHj9Iuk\\u003d\",\"ctxDetails\":\"{\\\"com.cloud.user.Account\\\":\\\"d08d73a5-b577-4082-a959-114b433979f1\\\"}\",\"cmdEventType\":\"ACCOUNT.DELETE\",\"ctxUserId\":\"2\",\"httpmethod\":\"GET\",\"_\":\"1416046428981\",\"uuid\":\"d08d73a5-b577-4082-a959-114b433979f1\",\"ctxAccountId\":\"2\",\"ctxStartEventId\":\"271\"}","instanceType":"Account","instanceUuid":"","jobId":"0749f13f-517b-4cba-81f2-c9a9d23445cd","status":"SUCCEEDED","processStatus":"0","commandEventType":"ACCOUNT.DELETE","resultCode":"0","command":"org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd","jobResult":"org.apache.cloudstack.api.response.SuccessResponse/null/{\"success\":true}","account":"fcf6dd7e-6983-11e4-bb12-066294db","user":"fcf71ae6-6983-11e4-bb12-066294db"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9077) injectkeys.sh doesn't work on CentOS7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022298#comment-15022298 ] ASF GitHub Bot commented on CLOUDSTACK-9077: Github user pdion891 commented on the pull request: https://github.com/apache/cloudstack/pull/1109#issuecomment-158973082 @remibergsma Thanks for this PR, this will break the injection of the ssh key in the initial build of the docker container. But I will submit a PR to fix the initial build of the image that work with this PR. So please go ahead with this PR, seams to make more sense then previous "in a container check". > injectkeys.sh doesn't work on CentOS7 > - > > Key: CLOUDSTACK-9077 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9077 > 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 >Reporter: Remi Bergsma >Priority: Critical > > Regression from: > https://github.com/apache/cloudstack/commit/3381154fafb7fa4f0a61d538f7c2550e48247787 > CentOS7 doesn't have /dev/loop0 so it fails. Removing the check makes it work > again. > ``` > 2015-11-20 21:51:16,145 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Executing: /bin/bash > /var/lib/tomcat/webapps/client/WEB-INF/classes/scripts/vm/systemvm/injectkeys.sh > /usr/share/tomc > at5/.ssh/id_rsa.pub /usr/share/tomcat5/.ssh/id_rsa > /var/lib/tomcat/webapps/client/WEB-INF/classes/vms/systemvm.iso > 2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Execution is successful. > 2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) No loop device found, skipping ssh key insertion > in systemvm.iso > 2015-11-20 21:51:16,162 INFO [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Injected public and private keys into systemvm > iso with result : null > ``` > Pinging [~pdion] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9077) injectkeys.sh doesn't work on CentOS7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022280#comment-15022280 ] ASF GitHub Bot commented on CLOUDSTACK-9077: GitHub user remibergsma opened a pull request: https://github.com/apache/cloudstack/pull/1109 CLOUDSTACK-9077 Fix injectkeys.sh to work on CentOS7 Fix regression from commit 3381154fafb7fa4f0a61d538f7c2550e48247787 The error seen on CentOS 7: ``` 2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] (localhost-startStop-1:null) No loop device found, skipping ssh key insertion in systemvm.iso ``` Instead of detecting `/dev/loop0` this checks if we run inside Docker. Tested on CentOS 7 and that now works again as expected. ``` 2015-11-23 16:20:16,777 DEBUG [c.c.s.ConfigurationServerImpl] (localhost-startStop-1:null) Executing: /bin/bash /var/lib/tomcat/webapps/client/WEB-INF/classes/scripts/vm/systemvm/injectkeys.sh /home/cloud/.ssh/id_rsa.pub /home/cl oud/.ssh/id_rsa /var/lib/tomcat/webapps/client/WEB-INF/classes/vms/systemvm.iso 2015-11-23 16:20:16,821 DEBUG [c.c.s.ConfigurationServerImpl] (localhost-startStop-1:null) Execution is successful. 2015-11-23 16:20:16,827 INFO [c.c.s.ConfigurationServerImpl] (localhost-startStop-1:null) Injected public and private keys into systemvm iso with result : null ``` Pinging @pdion891 to have a look. You can merge this pull request into a Git repository by running: $ git pull https://github.com/remibergsma/cloudstack fix-CLOUDSTACK-9077 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1109.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 #1109 commit fe91d9737d8424e6ed93a0c8ed42e58f248e5dc1 Author: Remi Bergsma Date: 2015-11-23T12:22:02Z CLOUDSTACK-9077 Fix injectkeys.sh to work on CentOS7 > injectkeys.sh doesn't work on CentOS7 > - > > Key: CLOUDSTACK-9077 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9077 > 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 >Reporter: Remi Bergsma >Priority: Critical > > Regression from: > https://github.com/apache/cloudstack/commit/3381154fafb7fa4f0a61d538f7c2550e48247787 > CentOS7 doesn't have /dev/loop0 so it fails. Removing the check makes it work > again. > ``` > 2015-11-20 21:51:16,145 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Executing: /bin/bash > /var/lib/tomcat/webapps/client/WEB-INF/classes/scripts/vm/systemvm/injectkeys.sh > /usr/share/tomc > at5/.ssh/id_rsa.pub /usr/share/tomcat5/.ssh/id_rsa > /var/lib/tomcat/webapps/client/WEB-INF/classes/vms/systemvm.iso > 2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Execution is successful. > 2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) No loop device found, skipping ssh key insertion > in systemvm.iso > 2015-11-20 21:51:16,162 INFO [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Injected public and private keys into systemvm > iso with result : null > ``` > Pinging [~pdion] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9047) rename enums to match best practice naming pattern
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022041#comment-15022041 ] ASF GitHub Bot commented on CLOUDSTACK-9047: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1049#issuecomment-158924625 @remibergsma : that was a fluke, it does compile and run unit tests now??? ``` [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 11:18 min [INFO] Finished at: 2015-11-23T13:44:50+01:00 [INFO] Final Memory: 119M/713M [INFO] ``` > rename enums to match best practice naming pattern > -- > > Key: CLOUDSTACK-9047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9047 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > Enums should have a name starting with a capital according to java best > practices. Rename those that don't and add unit tests where relevant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9080) Able to upload Volume greater than the Resource limit defined for Primary Storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022036#comment-15022036 ] ASF GitHub Bot commented on CLOUDSTACK-9080: GitHub user karuturi opened a pull request: https://github.com/apache/cloudstack/pull/1107 CLOUDSTACK-9080: Resource limits for Primary arent respected during attach primary store resource limit check is not performed while attaching a volume to a vm. Added them same. Also added a marvin test case to verify the same. Testing: BEFORE No error is shown in UI when trying to attach a volume even after reaching the resource limits. ``` mysql> select * from resource_limit where type="primary_storage"; ++---++-+-+ | id | domain_id | account_id | type| max | ++---++-+-+ | 10 | NULL | 4 | primary_storage | 21474836480 | ++---++-+-+ 1 row in set (0.00 sec) mysql> select * from resource_count where account_id=4 and type='primary_storage'; +++---+-+-+ | id | account_id | domain_id | type| count | +++---+-+-+ | 63 | 4 | NULL | primary_storage | 48318382080 | +++---+-+-+ 1 row in set (0.00 sec) ``` AFTER Following error message is shown in UI and the volume is not attached  The resource limits stays the same ``` mysql> select * from resource_limit where type="primary_storage"; ++---++-+-+ | id | domain_id | account_id | type| max | ++---++-+-+ | 10 | NULL | 4 | primary_storage | 21474836480 | ++---++-+-+ 1 row in set (0.01 sec) mysql> select * from resource_count where account_id=4 and type='primary_storage'; +++---+-+-+ | id | account_id | domain_id | type| count | +++---+-+-+ | 63 | 4 | NULL | primary_storage | 48318382080 | +++---+-+-+ 1 row in set (0.00 sec) ``` Marvin test: nosetests --with-marvin --marvin-config=setup/dev/advanced.cfg --zone=xen-zone0 --hypervisor=xenserver test/integration/component/test_ps_resource_limits_volume.py before the change ``` # do ... === TestName: test_attach_volume_exceeding_primary_limits | Status : FAILED === AssertionError: Resource count 23 should match with the expected resource count 22\n ``` After the change ``` # do ... === TestName: test_attach_volume_exceeding_primary_limits | Status : SUCCESS === ok -- Ran 1 test in 1178.354s OK ``` You can merge this pull request into a Git repository by running: $ git pull https://github.com/karuturi/cloudstack CLOUDSTACK-9080 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1107.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 #1107 commit 12756a79668b0b6eac253d9561b7145294a59873 Author: Rajani Karuturi Date: 2015-05-21T11:20:39Z CLOUDSTACK-9080: Resource limits for Primary arent respected during attach. primary store resource limit check is not performed while attaching a volume to a vm. Added them same. Also added a marvin test case to verify the same. > Able to upload Volume greater than the Resource limit defined for Primary > Storage. > -- > > Key: CLOUDSTACK-9080 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9080 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rajani Karuturi > > Steps : > 1. Create a child domain and create a User Account for the Respective child > domain. > 2. Edit the Primary Storage Resource limits for the account added above . > Limit
[jira] [Updated] (CLOUDSTACK-9080) Able to upload Volume greater than the Resource limit defined for Primary Storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-9080: Description: Steps : 1. Create a child domain and create a User Account for the Respective child domain. 2. Edit the Primary Storage Resource limits for the account added above . Limit being 200 GB , edit the value as 1Gb. 3. Try to upload volume greater than 1Gb. (Volume is successfully uploaded. ) 4. try attaching the volume to a vm. Result: attach volume is successful even though the resource limits reached. Expected: attach volume should fail with resource limit reached on primary exception. was: Steps : 1)Create a child domain and create a User Account for the Respective child domain. 2)Edit the Primary Storage Resource limits for the account added above . Limit being 200 GB , edit the value as 1Gb. 3)Try to upload volume greater than 1Gb. Result : Volume is successfully uploaded . Note : In case of Upload from URL , error message is displayed as " Maximum number of resources of type 'primary_storage' for account name=domuser in domain id=2 has been exceeded." > Able to upload Volume greater than the Resource limit defined for Primary > Storage. > -- > > Key: CLOUDSTACK-9080 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9080 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rajani Karuturi > > Steps : > 1. Create a child domain and create a User Account for the Respective child > domain. > 2. Edit the Primary Storage Resource limits for the account added above . > Limit being 200 GB , edit the value as 1Gb. > 3. Try to upload volume greater than 1Gb. (Volume is successfully uploaded. ) > 4. try attaching the volume to a vm. > Result: > attach volume is successful even though the resource limits reached. > Expected: > attach volume should fail with resource limit reached on primary exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9078) Scripts inside folder /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ aren't executable.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022027#comment-15022027 ] Boris Schrijver commented on CLOUDSTACK-9078: - It's for the cloudstack-management package. > Scripts inside folder > /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ > aren't executable. > - > > Key: CLOUDSTACK-9078 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9078 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver > Fix For: 4.7.0, 4.6.1 > > > Scripts inside folder > /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ > aren't executable. Therefore, when cloudstack tries to run one, it will get a > permission error and fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9080) Able to upload Volume greater than the Resource limit defined for Primary Storage.
Rajani Karuturi created CLOUDSTACK-9080: --- Summary: Able to upload Volume greater than the Resource limit defined for Primary Storage. Key: CLOUDSTACK-9080 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9080 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Rajani Karuturi Steps : 1)Create a child domain and create a User Account for the Respective child domain. 2)Edit the Primary Storage Resource limits for the account added above . Limit being 200 GB , edit the value as 1Gb. 3)Try to upload volume greater than 1Gb. Result : Volume is successfully uploaded . Note : In case of Upload from URL , error message is displayed as " Maximum number of resources of type 'primary_storage' for account name=domuser in domain id=2 has been exceeded." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9078) Scripts inside folder /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ aren't executable.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022016#comment-15022016 ] Remi Bergsma commented on CLOUDSTACK-9078: -- Is that in a specific package or for all packages? > Scripts inside folder > /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ > aren't executable. > - > > Key: CLOUDSTACK-9078 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9078 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver > Fix For: 4.7.0, 4.6.1 > > > Scripts inside folder > /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ > aren't executable. Therefore, when cloudstack tries to run one, it will get a > permission error and fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9047) rename enums to match best practice naming pattern
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022015#comment-15022015 ] ASF GitHub Bot commented on CLOUDSTACK-9047: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1049#issuecomment-158917040 @remibergsma this has probably been laying around to long. I did run unit tests and passed them but now compilation doesn't even succeed. I will put it back on log. > rename enums to match best practice naming pattern > -- > > Key: CLOUDSTACK-9047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9047 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > Enums should have a name starting with a capital according to java best > practices. Rename those that don't and add unit tests where relevant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9079) ipsec service is not running after restarting virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022014#comment-15022014 ] Remi Bergsma commented on CLOUDSTACK-9079: -- Bumped to critical to be able to see it in my filters. > ipsec service is not running after restarting virtual router > > > Key: CLOUDSTACK-9079 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9079 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM, Virtual Router >Affects Versions: 4.6.0 > Environment: ACS 4.5.1 upgraded to 4.6.0 >Reporter: Erik Weber >Priority: Critical > Labels: systemvm, virtualrouter, vpn > > after upgrading to 4.6.0 the ipsec service does no longer automatically start > and as an effect vpn does not work. > manually starting the ipsec service, or doing any vpn related configuration > (adding/deleting users) remedies the problem. > Steps to reproduce: > 1) Install ACS 4.6.0 > 2) Configure a VPC (I haven't tested with normal isolated networks) > 3) Enable remote access VPN, configure a user > 4) Confirm that VPN works > 5) Restart the VR > 6) Confirm that VPN does NOT work, either by trying to connect or by issuing > 'service ipsec status' on the VR -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9079) ipsec service is not running after restarting virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma updated CLOUDSTACK-9079: - Priority: Critical (was: Major) > ipsec service is not running after restarting virtual router > > > Key: CLOUDSTACK-9079 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9079 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM, Virtual Router >Affects Versions: 4.6.0 > Environment: ACS 4.5.1 upgraded to 4.6.0 >Reporter: Erik Weber >Priority: Critical > Labels: systemvm, virtualrouter, vpn > > after upgrading to 4.6.0 the ipsec service does no longer automatically start > and as an effect vpn does not work. > manually starting the ipsec service, or doing any vpn related configuration > (adding/deleting users) remedies the problem. > Steps to reproduce: > 1) Install ACS 4.6.0 > 2) Configure a VPC (I haven't tested with normal isolated networks) > 3) Enable remote access VPN, configure a user > 4) Confirm that VPN works > 5) Restart the VR > 6) Confirm that VPN does NOT work, either by trying to connect or by issuing > 'service ipsec status' on the VR -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9079) ipsec service is not running after restarting virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Weber updated CLOUDSTACK-9079: --- Description: after upgrading to 4.6.0 the ipsec service does no longer automatically start and as an effect vpn does not work. manually starting the ipsec service, or doing any vpn related configuration (adding/deleting users) remedies the problem. Steps to reproduce: 1) Install ACS 4.6.0 2) Configure a VPC (I haven't tested with normal isolated networks) 3) Enable remote access VPN, configure a user 4) Confirm that VPN works 5) Restart the VR 6) Confirm that VPN does NOT work, either by trying to connect or by issuing 'service ipsec status' on the VR was: after upgrading to 4.6.0 the ipsec service does no longer automatically start and as an effect vpn does not work. manually starting the ipsec service, or doing any vpn related configuration (adding/deleting users) remedies the problem. > ipsec service is not running after restarting virtual router > > > Key: CLOUDSTACK-9079 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9079 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM, Virtual Router >Affects Versions: 4.6.0 > Environment: ACS 4.5.1 upgraded to 4.6.0 >Reporter: Erik Weber > Labels: systemvm, virtualrouter, vpn > > after upgrading to 4.6.0 the ipsec service does no longer automatically start > and as an effect vpn does not work. > manually starting the ipsec service, or doing any vpn related configuration > (adding/deleting users) remedies the problem. > Steps to reproduce: > 1) Install ACS 4.6.0 > 2) Configure a VPC (I haven't tested with normal isolated networks) > 3) Enable remote access VPN, configure a user > 4) Confirm that VPN works > 5) Restart the VR > 6) Confirm that VPN does NOT work, either by trying to connect or by issuing > 'service ipsec status' on the VR -- 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=15022009#comment-15022009 ] ASF GitHub Bot commented on CLOUDSTACK-9020: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1106#issuecomment-158916248 Thanks @bhaisaab will test soon. > 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: 4.7.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-8958) add dedicated ips to domain
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022006#comment-15022006
]
ASF GitHub Bot commented on CLOUDSTACK-8958:
Github user ustcweizhou commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1007#discussion_r45596255
--- Diff: server/src/com/cloud/configuration/ConfigurationManagerImpl.java
---
@@ -3310,13 +3331,19 @@ public Vlan dedicatePublicIpRange(final
DedicatePublicIpRangeCmd cmd) throws Res
vlanOwner =
_accountMgr.getAccount(project.getProjectAccountId());
}
+Domain domain = null;
if (accountName != null && domainId != null) {
vlanOwner = _accountDao.findActiveAccount(accountName,
domainId);
-}
-if (vlanOwner == null) {
-throw new InvalidParameterValueException("Unable to find
account by name " + accountName);
-} else if (vlanOwner.getId() == Account.ACCOUNT_ID_SYSTEM) {
-throw new InvalidParameterValueException("Please specify a
valid account. Cannot dedicate IP range to system account");
+if (vlanOwner == null) {
--- End diff --
@remibergsma I added a second commit to fix it. However, it did not touch
these codes, but codebefore these.
> add dedicated ips to domain
> ---
>
> Key: CLOUDSTACK-8958
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> add dedicated ips to domain
> ips are dedicated to Account for now, so other customers and projects in the
> same domain will use the system ip. this is not what we need.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8958) add dedicated ips to domain
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022003#comment-15022003
]
ASF GitHub Bot commented on CLOUDSTACK-8958:
Github user remibergsma commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1007#discussion_r45595780
--- Diff: server/src/com/cloud/configuration/ConfigurationManagerImpl.java
---
@@ -3310,13 +3331,19 @@ public Vlan dedicatePublicIpRange(final
DedicatePublicIpRangeCmd cmd) throws Res
vlanOwner =
_accountMgr.getAccount(project.getProjectAccountId());
}
+Domain domain = null;
if (accountName != null && domainId != null) {
vlanOwner = _accountDao.findActiveAccount(accountName,
domainId);
-}
-if (vlanOwner == null) {
-throw new InvalidParameterValueException("Unable to find
account by name " + accountName);
-} else if (vlanOwner.getId() == Account.ACCOUNT_ID_SYSTEM) {
-throw new InvalidParameterValueException("Please specify a
valid account. Cannot dedicate IP range to system account");
+if (vlanOwner == null) {
--- End diff --
@ustcweizhou This PR is almost ready to be merged. Please respond to
comments above.
> add dedicated ips to domain
> ---
>
> Key: CLOUDSTACK-8958
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> add dedicated ips to domain
> ips are dedicated to Account for now, so other customers and projects in the
> same domain will use the system ip. this is not what we need.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8958) add dedicated ips to domain
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022002#comment-15022002
]
ASF GitHub Bot commented on CLOUDSTACK-8958:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1007#issuecomment-158914722
Repeated the tests due to new commits:
LGTM based on these tests:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,required_hardware=true \
component/test_vpc_redundant.py \
component/test_routers_iptables_default_policy.py \
component/test_routers_network_ops.py \
component/test_vpc_router_nics.py \
smoke/test_loadbalance.py \
smoke/test_internal_lb.py \
smoke/test_ssvm.py \
smoke/test_network.py
```
Result:
```
Test iptables default INPUT/FORWARD policies on VPC router ... ===
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test nics
after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status :
SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test default
routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS ===
ok
Check the password file in the Router VM ... === TestName:
test_isolate_network_password_server | Status : SUCCESS ===
ok
Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... ===
TestName: test_router_dhcphosts | Status : SUCCESS ===
ok
Test to create Load balancing rule with source NAT ... === TestName:
test_01_create_lb_rule_src_nat | Status : SUCCESS ===
ok
Test to create Load balancing rule with non source NAT ... === TestName:
test_02_create_lb_rule_non_nat | Status : SUCCESS ===
ok
Test for assign & removing load balancing rule ... === TestName:
test_assign_and_removal_lb | Status : SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... ===
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80
| Status : SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status :
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status :
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS
===
ok
Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS
===
ok
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS
===
ok
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS
===
ok
Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn
| Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS
===
ok
Test for port forwarding on source NAT ... === TestName:
test_01_port_fwd_on_src_nat | Status : SUCCESS ===
ok
Test for port forwarding on non source NAT ... === TestName:
test_02_port_fwd_on_non_src_nat | Status : SUCCESS ===
ok
Test for reboot router ... === TestName: test_reboot_router | Status :
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status :
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : SUCCESS
===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | Status :
SUCCESS ===
ok
--
Ran 33 tests in 168011.715s
OK
```
And:
```
nosetests --with-marvin --marvi
[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=15021998#comment-15021998 ] ASF subversion and git services commented on CLOUDSTACK-8485: - Commit a2a72887d205f9ed51c0b31014ab3bd6e571ea4d in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a2a7288 ] Merge pull request #1021 from koushik-das/CLOUDSTACK-8485 CLOUDSTACK-8485: listAPIs are taking too long to return results- Removed regex. based search/replace of sensitive data on API response introduced as part of commit b0c6d4734724358df97b6fa4d8c5beb0f447745e - Added new response serializer to skip sensitive data from getting logged based on annotation present in resposne object fields - Added annotation (@LogLevel(Log4jLevel.Off)) to sensitive response object fields Ran the following tests on simulator: test_vm_life_cycle.py 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 -- Ran 10 tests in 306.429s OK test_volumes.py Download a Volume attached to a VM ... === TestName: test_03_download_attached_volume | Status : SUCCESS === ok Delete a Volume attached to a VM ... === TestName: test_04_delete_attached_volume | Status : SUCCESS === ok Detach a Volume attached to a VM ... === TestName: test_05_detach_volume | Status : SUCCESS === ok Delete a Volume unattached to an VM ... === TestName: test_09_delete_detached_volume | Status : SUCCESS === ok -- Ran 4 tests in 184.132s OK test_network.py 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 -- Ran 4 tests in 783.726s OK test_routers.py Test router internal advanced zone ... SKIP: Marvin configuration has no host credentialsto check router services 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 -- Ran 7 tests in 42.958s OK (SKIP=1) test_global_settings.py test update configuration setting at zone level scope ... === TestName: test_UpdateConfigParamWithScope | Status : SUCCESS === ok -- Ran 1 test in 0.127s OK test_resource_detail.py Test volume detail ... === TestName: test_01_updatevolumedetail | Status : SUCCESS === ok -- Ran 1 test in 11.492s OK * pr/1021: CLOUDSTACK-8485: listAPIs are taking too long to return results - Removed regex. based search/replace of sensitive data on API response introduced as part of commit b0c6d4734724358df97b6fa4d8c5beb0f447745e - Added new response serializer to skip sensitive data from getting logged based on annotation present in resposne object fields - Added new parameter 'isSensitive' to @Param for marking a field as sensitive in response objects Signed-off-by: Remi Bergsma > listAPIs are taking too long to return r
[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=15022000#comment-15022000 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1021 > 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.data_center_id, > host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, > host.parent, host.guid, host.capabilities, host.tota
[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=15021996#comment-15021996 ] ASF subversion and git services commented on CLOUDSTACK-8485: - Commit e13df96348c60694849f91d0c025cb349aea124e in cloudstack's branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e13df96 ] CLOUDSTACK-8485: listAPIs are taking too long to return results - Removed regex. based search/replace of sensitive data on API response introduced as part of commit b0c6d4734724358df97b6fa4d8c5beb0f447745e - Added new response serializer to skip sensitive data from getting logged based on annotation present in resposne object fields - Added new parameter 'isSensitive' to @Param for marking a field as sensitive in response objects > 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.pu
[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=15021999#comment-15021999 ] ASF subversion and git services commented on CLOUDSTACK-8485: - Commit a2a72887d205f9ed51c0b31014ab3bd6e571ea4d in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a2a7288 ] Merge pull request #1021 from koushik-das/CLOUDSTACK-8485 CLOUDSTACK-8485: listAPIs are taking too long to return results- Removed regex. based search/replace of sensitive data on API response introduced as part of commit b0c6d4734724358df97b6fa4d8c5beb0f447745e - Added new response serializer to skip sensitive data from getting logged based on annotation present in resposne object fields - Added annotation (@LogLevel(Log4jLevel.Off)) to sensitive response object fields Ran the following tests on simulator: test_vm_life_cycle.py 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 -- Ran 10 tests in 306.429s OK test_volumes.py Download a Volume attached to a VM ... === TestName: test_03_download_attached_volume | Status : SUCCESS === ok Delete a Volume attached to a VM ... === TestName: test_04_delete_attached_volume | Status : SUCCESS === ok Detach a Volume attached to a VM ... === TestName: test_05_detach_volume | Status : SUCCESS === ok Delete a Volume unattached to an VM ... === TestName: test_09_delete_detached_volume | Status : SUCCESS === ok -- Ran 4 tests in 184.132s OK test_network.py 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 -- Ran 4 tests in 783.726s OK test_routers.py Test router internal advanced zone ... SKIP: Marvin configuration has no host credentialsto check router services 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 -- Ran 7 tests in 42.958s OK (SKIP=1) test_global_settings.py test update configuration setting at zone level scope ... === TestName: test_UpdateConfigParamWithScope | Status : SUCCESS === ok -- Ran 1 test in 0.127s OK test_resource_detail.py Test volume detail ... === TestName: test_01_updatevolumedetail | Status : SUCCESS === ok -- Ran 1 test in 11.492s OK * pr/1021: CLOUDSTACK-8485: listAPIs are taking too long to return results - Removed regex. based search/replace of sensitive data on API response introduced as part of commit b0c6d4734724358df97b6fa4d8c5beb0f447745e - Added new response serializer to skip sensitive data from getting logged based on annotation present in resposne object fields - Added new parameter 'isSensitive' to @Param for marking a field as sensitive in response objects Signed-off-by: Remi Bergsma > listAPIs are taking too long to return r
[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=15021997#comment-15021997 ] ASF subversion and git services commented on CLOUDSTACK-8485: - Commit a2a72887d205f9ed51c0b31014ab3bd6e571ea4d in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a2a7288 ] Merge pull request #1021 from koushik-das/CLOUDSTACK-8485 CLOUDSTACK-8485: listAPIs are taking too long to return results- Removed regex. based search/replace of sensitive data on API response introduced as part of commit b0c6d4734724358df97b6fa4d8c5beb0f447745e - Added new response serializer to skip sensitive data from getting logged based on annotation present in resposne object fields - Added annotation (@LogLevel(Log4jLevel.Off)) to sensitive response object fields Ran the following tests on simulator: test_vm_life_cycle.py 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 -- Ran 10 tests in 306.429s OK test_volumes.py Download a Volume attached to a VM ... === TestName: test_03_download_attached_volume | Status : SUCCESS === ok Delete a Volume attached to a VM ... === TestName: test_04_delete_attached_volume | Status : SUCCESS === ok Detach a Volume attached to a VM ... === TestName: test_05_detach_volume | Status : SUCCESS === ok Delete a Volume unattached to an VM ... === TestName: test_09_delete_detached_volume | Status : SUCCESS === ok -- Ran 4 tests in 184.132s OK test_network.py 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 -- Ran 4 tests in 783.726s OK test_routers.py Test router internal advanced zone ... SKIP: Marvin configuration has no host credentialsto check router services 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 -- Ran 7 tests in 42.958s OK (SKIP=1) test_global_settings.py test update configuration setting at zone level scope ... === TestName: test_UpdateConfigParamWithScope | Status : SUCCESS === ok -- Ran 1 test in 0.127s OK test_resource_detail.py Test volume detail ... === TestName: test_01_updatevolumedetail | Status : SUCCESS === ok -- Ran 1 test in 11.492s OK * pr/1021: CLOUDSTACK-8485: listAPIs are taking too long to return results - Removed regex. based search/replace of sensitive data on API response introduced as part of commit b0c6d4734724358df97b6fa4d8c5beb0f447745e - Added new response serializer to skip sensitive data from getting logged based on annotation present in resposne object fields - Added new parameter 'isSensitive' to @Param for marking a field as sensitive in response objects Signed-off-by: Remi Bergsma > listAPIs are taking too long to return r
[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=15021942#comment-15021942 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-158903497 Saw the changes, LGTM > 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.data_center_id, > host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram
[jira] [Created] (CLOUDSTACK-9079) ipsec service is not running after restarting virtual router
Erik Weber created CLOUDSTACK-9079: -- Summary: ipsec service is not running after restarting virtual router Key: CLOUDSTACK-9079 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9079 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM, Virtual Router Affects Versions: 4.6.0 Environment: ACS 4.5.1 upgraded to 4.6.0 Reporter: Erik Weber after upgrading to 4.6.0 the ipsec service does no longer automatically start and as an effect vpn does not work. manually starting the ipsec service, or doing any vpn related configuration (adding/deleting users) remedies the problem. -- 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=15021925#comment-15021925
]
ASF GitHub Bot commented on CLOUDSTACK-8485:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1021#issuecomment-158901685
LGTM based on these tests (may not have tested the actual change):
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,required_hardware=true \
component/test_vpc_redundant.py \
component/test_routers_iptables_default_policy.py \
component/test_routers_network_ops.py \
component/test_vpc_router_nics.py \
smoke/test_loadbalance.py \
smoke/test_internal_lb.py \
smoke/test_ssvm.py \
smoke/test_network.py
```
Result:
```
Test iptables default INPUT/FORWARD policies on VPC router ... ===
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test nics
after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status :
SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test default
routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS ===
ok
Check the password file in the Router VM ... === TestName:
test_isolate_network_password_server | Status : SUCCESS ===
ok
Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... ===
TestName: test_router_dhcphosts | Status : SUCCESS ===
ok
Test to create Load balancing rule with source NAT ... === TestName:
test_01_create_lb_rule_src_nat | Status : SUCCESS ===
ok
Test to create Load balancing rule with non source NAT ... === TestName:
test_02_create_lb_rule_non_nat | Status : SUCCESS ===
ok
Test for assign & removing load balancing rule ... === TestName:
test_assign_and_removal_lb | Status : SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... ===
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80
| Status : SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status :
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status :
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS
===
ok
Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS
===
ok
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS
===
ok
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS
===
ok
Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn
| Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS
===
ok
Test for port forwarding on source NAT ... === TestName:
test_01_port_fwd_on_src_nat | Status : SUCCESS ===
ok
Test for port forwarding on non source NAT ... === TestName:
test_02_port_fwd_on_non_src_nat | Status : SUCCESS ===
ok
Test for reboot router ... === TestName: test_reboot_router | Status :
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status :
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : SUCCESS
===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | Status :
SUCCESS ===
ok
--
Ran 33 tests in 17014.931s
OK
```
And:
```
nosetests --with-marvin --marvin-config=
[jira] [Commented] (CLOUDSTACK-9047) rename enums to match best practice naming pattern
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021921#comment-15021921 ] ASF GitHub Bot commented on CLOUDSTACK-9047: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1049#issuecomment-158901139 @wido @DaanHoogland @wilderrodrigues Did any of you run the unit test and did they pass? If so, please paste output. After this, OK to merge? > rename enums to match best practice naming pattern > -- > > Key: CLOUDSTACK-9047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9047 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > Enums should have a name starting with a capital according to java best > practices. Rename those that don't and add unit tests where relevant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9047) rename enums to match best practice naming pattern
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021920#comment-15021920
]
ASF GitHub Bot commented on CLOUDSTACK-9047:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1049#issuecomment-158901032
LGTM based on these tests:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,required_hardware=true \
component/test_vpc_redundant.py \
component/test_routers_iptables_default_policy.py \
component/test_routers_network_ops.py \
component/test_vpc_router_nics.py \
smoke/test_loadbalance.py \
smoke/test_internal_lb.py \
smoke/test_ssvm.py \
smoke/test_network.py
```
Result:
```
Test iptables default INPUT/FORWARD policies on VPC router ... ===
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test nics
after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status :
SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test default
routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS ===
ok
Check the password file in the Router VM ... === TestName:
test_isolate_network_password_server | Status : SUCCESS ===
ok
Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... ===
TestName: test_router_dhcphosts | Status : SUCCESS ===
ok
Test to create Load balancing rule with source NAT ... === TestName:
test_01_create_lb_rule_src_nat | Status : SUCCESS ===
ok
Test to create Load balancing rule with non source NAT ... === TestName:
test_02_create_lb_rule_non_nat | Status : SUCCESS ===
ok
Test for assign & removing load balancing rule ... === TestName:
test_assign_and_removal_lb | Status : SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... ===
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80
| Status : SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status :
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status :
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS
===
ok
Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS
===
ok
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS
===
ok
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS
===
ok
Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn
| Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS
===
ok
Test for port forwarding on source NAT ... === TestName:
test_01_port_fwd_on_src_nat | Status : SUCCESS ===
ok
Test for port forwarding on non source NAT ... === TestName:
test_02_port_fwd_on_non_src_nat | Status : SUCCESS ===
ok
Test for reboot router ... === TestName: test_reboot_router | Status :
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status :
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : SUCCESS
===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | Status :
SUCCESS ===
ok
--
Ran 33 tests in 17470.886s
OK
```
And:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,requir
[jira] [Commented] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021919#comment-15021919 ] ASF GitHub Bot commented on CLOUDSTACK-9068: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1081#issuecomment-158900212 I was wondering; as it seems obvious from your screenshot that initial rendering works, after an item (i.e. row) has been added, whether it also re-renders ok after adjusting tables columns or resizing the window/frame. The patch is a simple removal of a render helper. I didn't take time to test yet. > Listing Port Forwarding Rules take too much time to load > > > Key: CLOUDSTACK-9068 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9068 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > ISSUE > == > The performance of listPortForwardingRules slows down dramatically as the > number of rules for an IP increases. If there are 100 rules for an IP and it > takes over a minute to respond. > REPRODUCE STEPS > == > 1) Create many port forwarding rules (75-100) for a particular IP. > 2) View the port forwarding rules for the IP in the UI or directly with the > listPortForwardingRules API command. > 3) Notice the slowness. > EXPECTED BEHAVIOR > == > listPortForwardingRules should always respond in a reasonable time. > ACTUAL BEHAVIOR > == > listPortForwardingRules responds very slowly even with less than 100 rules > configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021912#comment-15021912 ] ASF GitHub Bot commented on CLOUDSTACK-9068: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1081#issuecomment-158898488 @DaanHoogland Is that what you mean.. testing it with the wider UI or..? > Listing Port Forwarding Rules take too much time to load > > > Key: CLOUDSTACK-9068 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9068 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > ISSUE > == > The performance of listPortForwardingRules slows down dramatically as the > number of rules for an IP increases. If there are 100 rules for an IP and it > takes over a minute to respond. > REPRODUCE STEPS > == > 1) Create many port forwarding rules (75-100) for a particular IP. > 2) View the port forwarding rules for the IP in the UI or directly with the > listPortForwardingRules API command. > 3) Notice the slowness. > EXPECTED BEHAVIOR > == > listPortForwardingRules should always respond in a reasonable time. > ACTUAL BEHAVIOR > == > listPortForwardingRules responds very slowly even with less than 100 rules > configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8951) UI is not throwing any error message to user when "remote.access.vpn.psk.length" is set to less than minimum value (min8)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021904#comment-15021904 ] ASF GitHub Bot commented on CLOUDSTACK-8951: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/929 > UI is not throwing any error message to user when > "remote.access.vpn.psk.length" is set to less than minimum value (min8) > - > > Key: CLOUDSTACK-8951 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8951 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rajani Karuturi >Priority: Critical > > 1. Changed the global configuration "remote.access.vpn.psk.length" to 5 but > the minimum value is 8. > 2. restart the MS. > Ms failed to restart with following exception: > 015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Build message handler cache for > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor > 2015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Add message handler > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor.onJobHeartbeatNotify > to cache > 2015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Done building message handler cache for > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor > 2015-09-16 06:08:54,231 DEBUG [c.c.a.m.AgentManagerImpl] (main:null) (logid:) > Registering listener DeploymentPlanningManagerImpl with id 9 > 2015-09-16 06:08:54,278 ERROR [o.a.c.s.l.CloudStackExtendedLifeCycle] > (main:null) (logid:) Failed to configure RemoteAccessVpnManagerImpl > javax.naming.ConfigurationException: Remote Access VPN: IPSec preshared key > length should be between 8 and 256 > at > com.cloud.network.vpn.RemoteAccessVpnManagerImpl.validateRemoteAccessVpnConfiguration(RemoteAccessVpnManagerImpl.java:268) > at > com.cloud.network.vpn.RemoteAccessVpnManagerImpl.configure(RemoteAccessVpnManagerImpl.java:694) > 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 $Proxy233.configure(Unknown Source) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle$3.with(CloudStackExtendedLifeCycle.java:114) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.with(CloudStackExtendedLifeCycle.java:153) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.configure(CloudStackExtendedLifeCycle.java:110) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:56) > at > org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167) > at > org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51) > at > org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339) > at > org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143) > at org > But Even before restart of MS, > UI should throw proper error message to the user. > Attaching the Mslogs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8951) UI is not throwing any error message to user when "remote.access.vpn.psk.length" is set to less than minimum value (min8)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021903#comment-15021903 ] ASF subversion and git services commented on CLOUDSTACK-8951: - Commit 3f6d7796f1f43d1eab622f3922c1efcba68d911c in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3f6d779 ] Merge pull request #929 from karuturi/CLOUDSTACK-8951 [4.7] CLOUDSTACK-8951: validation for config param "remote.access.vpn.psk.length"throwing error for value < 8 and value > 256 right now, 8, 256 are hardcoded in the code. They should be moved to a constant and has to be reused everywhere. will update with test cases/testing later. * pr/929: CLOUDSTACK-8951: validation for "remote.access.vpn.psk.length" Signed-off-by: Remi Bergsma > UI is not throwing any error message to user when > "remote.access.vpn.psk.length" is set to less than minimum value (min8) > - > > Key: CLOUDSTACK-8951 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8951 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rajani Karuturi >Priority: Critical > > 1. Changed the global configuration "remote.access.vpn.psk.length" to 5 but > the minimum value is 8. > 2. restart the MS. > Ms failed to restart with following exception: > 015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Build message handler cache for > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor > 2015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Add message handler > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor.onJobHeartbeatNotify > to cache > 2015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Done building message handler cache for > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor > 2015-09-16 06:08:54,231 DEBUG [c.c.a.m.AgentManagerImpl] (main:null) (logid:) > Registering listener DeploymentPlanningManagerImpl with id 9 > 2015-09-16 06:08:54,278 ERROR [o.a.c.s.l.CloudStackExtendedLifeCycle] > (main:null) (logid:) Failed to configure RemoteAccessVpnManagerImpl > javax.naming.ConfigurationException: Remote Access VPN: IPSec preshared key > length should be between 8 and 256 > at > com.cloud.network.vpn.RemoteAccessVpnManagerImpl.validateRemoteAccessVpnConfiguration(RemoteAccessVpnManagerImpl.java:268) > at > com.cloud.network.vpn.RemoteAccessVpnManagerImpl.configure(RemoteAccessVpnManagerImpl.java:694) > 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 $Proxy233.configure(Unknown Source) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle$3.with(CloudStackExtendedLifeCycle.java:114) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.with(CloudStackExtendedLifeCycle.java:153) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.configure(CloudStackExtendedLifeCycle.java:110) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:56) > at > org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167) > at > org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51) > at > org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339) > at > org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifec
[jira] [Commented] (CLOUDSTACK-8951) UI is not throwing any error message to user when "remote.access.vpn.psk.length" is set to less than minimum value (min8)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021900#comment-15021900 ] ASF subversion and git services commented on CLOUDSTACK-8951: - Commit 170a0257872954637b4f6ea1088aec5524b32961 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=170a025 ] CLOUDSTACK-8951: validation for "remote.access.vpn.psk.length" throwing error for value < 8 and value > 256 right now, 8, 256 are hardcoded in the code. They should be moved to a constant and has to be reused everywhere. > UI is not throwing any error message to user when > "remote.access.vpn.psk.length" is set to less than minimum value (min8) > - > > Key: CLOUDSTACK-8951 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8951 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rajani Karuturi >Priority: Critical > > 1. Changed the global configuration "remote.access.vpn.psk.length" to 5 but > the minimum value is 8. > 2. restart the MS. > Ms failed to restart with following exception: > 015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Build message handler cache for > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor > 2015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Add message handler > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor.onJobHeartbeatNotify > to cache > 2015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Done building message handler cache for > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor > 2015-09-16 06:08:54,231 DEBUG [c.c.a.m.AgentManagerImpl] (main:null) (logid:) > Registering listener DeploymentPlanningManagerImpl with id 9 > 2015-09-16 06:08:54,278 ERROR [o.a.c.s.l.CloudStackExtendedLifeCycle] > (main:null) (logid:) Failed to configure RemoteAccessVpnManagerImpl > javax.naming.ConfigurationException: Remote Access VPN: IPSec preshared key > length should be between 8 and 256 > at > com.cloud.network.vpn.RemoteAccessVpnManagerImpl.validateRemoteAccessVpnConfiguration(RemoteAccessVpnManagerImpl.java:268) > at > com.cloud.network.vpn.RemoteAccessVpnManagerImpl.configure(RemoteAccessVpnManagerImpl.java:694) > 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 $Proxy233.configure(Unknown Source) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle$3.with(CloudStackExtendedLifeCycle.java:114) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.with(CloudStackExtendedLifeCycle.java:153) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.configure(CloudStackExtendedLifeCycle.java:110) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:56) > at > org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167) > at > org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51) > at > org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339) > at > org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143) > at org > But Even before restart of MS, > UI should throw proper error message to the user. > Attaching the Mslogs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8951) UI is not throwing any error message to user when "remote.access.vpn.psk.length" is set to less than minimum value (min8)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021902#comment-15021902 ] ASF subversion and git services commented on CLOUDSTACK-8951: - Commit 3f6d7796f1f43d1eab622f3922c1efcba68d911c in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3f6d779 ] Merge pull request #929 from karuturi/CLOUDSTACK-8951 [4.7] CLOUDSTACK-8951: validation for config param "remote.access.vpn.psk.length"throwing error for value < 8 and value > 256 right now, 8, 256 are hardcoded in the code. They should be moved to a constant and has to be reused everywhere. will update with test cases/testing later. * pr/929: CLOUDSTACK-8951: validation for "remote.access.vpn.psk.length" Signed-off-by: Remi Bergsma > UI is not throwing any error message to user when > "remote.access.vpn.psk.length" is set to less than minimum value (min8) > - > > Key: CLOUDSTACK-8951 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8951 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rajani Karuturi >Priority: Critical > > 1. Changed the global configuration "remote.access.vpn.psk.length" to 5 but > the minimum value is 8. > 2. restart the MS. > Ms failed to restart with following exception: > 015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Build message handler cache for > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor > 2015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Add message handler > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor.onJobHeartbeatNotify > to cache > 2015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Done building message handler cache for > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor > 2015-09-16 06:08:54,231 DEBUG [c.c.a.m.AgentManagerImpl] (main:null) (logid:) > Registering listener DeploymentPlanningManagerImpl with id 9 > 2015-09-16 06:08:54,278 ERROR [o.a.c.s.l.CloudStackExtendedLifeCycle] > (main:null) (logid:) Failed to configure RemoteAccessVpnManagerImpl > javax.naming.ConfigurationException: Remote Access VPN: IPSec preshared key > length should be between 8 and 256 > at > com.cloud.network.vpn.RemoteAccessVpnManagerImpl.validateRemoteAccessVpnConfiguration(RemoteAccessVpnManagerImpl.java:268) > at > com.cloud.network.vpn.RemoteAccessVpnManagerImpl.configure(RemoteAccessVpnManagerImpl.java:694) > 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 $Proxy233.configure(Unknown Source) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle$3.with(CloudStackExtendedLifeCycle.java:114) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.with(CloudStackExtendedLifeCycle.java:153) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.configure(CloudStackExtendedLifeCycle.java:110) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:56) > at > org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167) > at > org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51) > at > org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339) > at > org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifec
[jira] [Commented] (CLOUDSTACK-8951) UI is not throwing any error message to user when "remote.access.vpn.psk.length" is set to less than minimum value (min8)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021901#comment-15021901 ] ASF subversion and git services commented on CLOUDSTACK-8951: - Commit 3f6d7796f1f43d1eab622f3922c1efcba68d911c in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3f6d779 ] Merge pull request #929 from karuturi/CLOUDSTACK-8951 [4.7] CLOUDSTACK-8951: validation for config param "remote.access.vpn.psk.length"throwing error for value < 8 and value > 256 right now, 8, 256 are hardcoded in the code. They should be moved to a constant and has to be reused everywhere. will update with test cases/testing later. * pr/929: CLOUDSTACK-8951: validation for "remote.access.vpn.psk.length" Signed-off-by: Remi Bergsma > UI is not throwing any error message to user when > "remote.access.vpn.psk.length" is set to less than minimum value (min8) > - > > Key: CLOUDSTACK-8951 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8951 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rajani Karuturi >Priority: Critical > > 1. Changed the global configuration "remote.access.vpn.psk.length" to 5 but > the minimum value is 8. > 2. restart the MS. > Ms failed to restart with following exception: > 015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Build message handler cache for > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor > 2015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Add message handler > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor.onJobHeartbeatNotify > to cache > 2015-09-16 06:08:54,230 INFO [o.a.c.f.m.MessageDispatcher] (main:null) > (logid:) Done building message handler cache for > org.apache.cloudstack.framework.jobs.impl.AsyncJobMonitor > 2015-09-16 06:08:54,231 DEBUG [c.c.a.m.AgentManagerImpl] (main:null) (logid:) > Registering listener DeploymentPlanningManagerImpl with id 9 > 2015-09-16 06:08:54,278 ERROR [o.a.c.s.l.CloudStackExtendedLifeCycle] > (main:null) (logid:) Failed to configure RemoteAccessVpnManagerImpl > javax.naming.ConfigurationException: Remote Access VPN: IPSec preshared key > length should be between 8 and 256 > at > com.cloud.network.vpn.RemoteAccessVpnManagerImpl.validateRemoteAccessVpnConfiguration(RemoteAccessVpnManagerImpl.java:268) > at > com.cloud.network.vpn.RemoteAccessVpnManagerImpl.configure(RemoteAccessVpnManagerImpl.java:694) > 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 $Proxy233.configure(Unknown Source) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle$3.with(CloudStackExtendedLifeCycle.java:114) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.with(CloudStackExtendedLifeCycle.java:153) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.configure(CloudStackExtendedLifeCycle.java:110) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:56) > at > org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167) > at > org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51) > at > org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339) > at > org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifec
[jira] [Commented] (CLOUDSTACK-8951) UI is not throwing any error message to user when "remote.access.vpn.psk.length" is set to less than minimum value (min8)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021896#comment-15021896
]
ASF GitHub Bot commented on CLOUDSTACK-8951:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/929#issuecomment-158897259
Run the tests again since master moved on quite a bit in the past weeks.
Still LGTM based on these tests:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,required_hardware=true \
component/test_vpc_redundant.py \
component/test_routers_iptables_default_policy.py \
component/test_routers_network_ops.py \
component/test_vpc_router_nics.py \
smoke/test_loadbalance.py \
smoke/test_internal_lb.py \
smoke/test_ssvm.py \
smoke/test_network.py
```
Result:
```
Test iptables default INPUT/FORWARD policies on VPC router ... ===
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test nics
after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status :
SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test default
routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS ===
ok
Check the password file in the Router VM ... === TestName:
test_isolate_network_password_server | Status : SUCCESS ===
ok
Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... ===
TestName: test_router_dhcphosts | Status : SUCCESS ===
ok
Test to create Load balancing rule with source NAT ... === TestName:
test_01_create_lb_rule_src_nat | Status : SUCCESS ===
ok
Test to create Load balancing rule with non source NAT ... === TestName:
test_02_create_lb_rule_non_nat | Status : SUCCESS ===
ok
Test for assign & removing load balancing rule ... === TestName:
test_assign_and_removal_lb | Status : SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... ===
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80
| Status : SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status :
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status :
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS
===
ok
Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS
===
ok
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS
===
ok
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS
===
ok
Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn
| Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS
===
ok
Test for port forwarding on source NAT ... === TestName:
test_01_port_fwd_on_src_nat | Status : SUCCESS ===
ok
Test for port forwarding on non source NAT ... === TestName:
test_02_port_fwd_on_non_src_nat | Status : SUCCESS ===
ok
Test for reboot router ... === TestName: test_reboot_router | Status :
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status :
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : SUCCESS
===
ok
Test for Router rules for network rules on acquired public IP ... ===
TestName: test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | Status :
SUCCESS ===
ok
--
Ran 33 tests in 15221.229s
OK
```
And:
`
[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=15021719#comment-15021719 ] ASF GitHub Bot commented on CLOUDSTACK-9037: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1035#issuecomment-158875017 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-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=15021718#comment-15021718
]
ASF GitHub Bot commented on CLOUDSTACK-8937:
Github user bhaisaab commented on the pull request:
https://github.com/apache/cloudstack/pull/1037#issuecomment-158875003
LGTM, anyone tested this yet?
> 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
> com.google.gson.ReflectingFieldNavigator.visitFieldsReflective
[jira] [Commented] (CLOUDSTACK-8818) Python scripts should depend on mysql.connector instead of MySQLdb
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021716#comment-15021716 ] ASF GitHub Bot commented on CLOUDSTACK-8818: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1054#issuecomment-158874821 LGTM > Python scripts should depend on mysql.connector instead of MySQLdb > -- > > Key: CLOUDSTACK-8818 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8818 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wido den Hollander > Labels: mysql, python, python3 > > Our current Python scripts depend on MySQLdb for MySQL connections. > The best way to go is the native mysql.connector which implements the MySQL > protocol in native Python instead of depending on external libraries. > It would be best if we drop MySQLdb and use mysql.connector since that also > supports Python 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9069) Newly added project is not showing in the drop down until the browser is refreshed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021714#comment-15021714 ] ASF GitHub Bot commented on CLOUDSTACK-9069: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1077#issuecomment-158874596 LGTM > Newly added project is not showing in the drop down until the browser is > refreshed. > --- > > Key: CLOUDSTACK-9069 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9069 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > Steps to reproduce: > 1.Login as admin and navigate to Projects page. > 2.Add one project and navigate to Dashboard. > 3.Check for newly added project in Project drop down. > Actual behaviour: > New project is showing in drop down only after refreshing the browser. > Expected behaviour: > New project should be shown in drop down without refreshing the browser also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9069) Newly added project is not showing in the drop down until the browser is refreshed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021712#comment-15021712 ] ASF GitHub Bot commented on CLOUDSTACK-9069: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1082#issuecomment-158874507 LGTM > Newly added project is not showing in the drop down until the browser is > refreshed. > --- > > Key: CLOUDSTACK-9069 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9069 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > Steps to reproduce: > 1.Login as admin and navigate to Projects page. > 2.Add one project and navigate to Dashboard. > 3.Check for newly added project in Project drop down. > Actual behaviour: > New project is showing in drop down only after refreshing the browser. > Expected behaviour: > New project should be shown in drop down without refreshing the browser also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9068) Listing Port Forwarding Rules take too much time to load
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021713#comment-15021713 ] ASF GitHub Bot commented on CLOUDSTACK-9068: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1081#issuecomment-158874568 LGTM, haven't tested with resized UI though > Listing Port Forwarding Rules take too much time to load > > > Key: CLOUDSTACK-9068 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9068 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > ISSUE > == > The performance of listPortForwardingRules slows down dramatically as the > number of rules for an IP increases. If there are 100 rules for an IP and it > takes over a minute to respond. > REPRODUCE STEPS > == > 1) Create many port forwarding rules (75-100) for a particular IP. > 2) View the port forwarding rules for the IP in the UI or directly with the > listPortForwardingRules API command. > 3) Notice the slowness. > EXPECTED BEHAVIOR > == > listPortForwardingRules should always respond in a reasonable time. > ACTUAL BEHAVIOR > == > listPortForwardingRules responds very slowly even with less than 100 rules > configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
