[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989099#comment-14989099 ] ASF GitHub Bot commented on CLOUDSTACK-8832: Github user runseb commented on the pull request: https://github.com/apache/cloudstack/pull/801#issuecomment-153629584 @jburwell I hear what you are saying, but I think it would be totally unfair to ask this plugin provider to provide independent testing capability to the community. No other vendor plugin has been asked to do this and deciding to do this should not be done on a PR. 1- This PR has been submitted for sometime, and has had quite thorough review 2- The contributors are showing great respect, understanding and will to work with the community 3- As you mention other plugins are not tested independently, e.g Solidfire is maintained by Mike T and he did not even contribute his Marvin tests...Vmware NSX ?... I'd rather work on a policy for removing dead code and abandoned plugins on the mailing list, than stop this great feature from being merged because we suddenly want to raise the bar and impose new way of testing third-party plugins. The request to have a way for the community to test this independently of Nuage is valid but I would like to work with them in the coming month(s) to make this happen, rather than put a burden that has never existed on them now. +1 for merge in 4.6 > Update Nuage VSP plugin to work with Nuage VSP release 3.2 > -- > > Key: CLOUDSTACK-8832 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Nick Livens >Assignee: Nick Livens > Attachments: nuageVspMarvinLogs.tar.gz > > > Nuage VSP 3.2 is being released, we want to bring the plugin up to date for > this release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989105#comment-14989105 ] ASF GitHub Bot commented on CLOUDSTACK-8832: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/801#issuecomment-153631129 @runseb I am with you but for 4.7 instead of 4.6. The Nuage people have shown great effort of elegantly using our crappy plugin system and are now maintaining it. We should use extreme prejudice in merging it for all kinds of reasons. > Update Nuage VSP plugin to work with Nuage VSP release 3.2 > -- > > Key: CLOUDSTACK-8832 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Nick Livens >Assignee: Nick Livens > Attachments: nuageVspMarvinLogs.tar.gz > > > Nuage VSP 3.2 is being released, we want to bring the plugin up to date for > this release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989107#comment-14989107 ] ASF GitHub Bot commented on CLOUDSTACK-8832: Github user runseb commented on the pull request: https://github.com/apache/cloudstack/pull/801#issuecomment-153631839 @DaanHoogland yep, so we can release this right on the heel of 4.6 release, with just one commit to get 4.7. > Update Nuage VSP plugin to work with Nuage VSP release 3.2 > -- > > Key: CLOUDSTACK-8832 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Nick Livens >Assignee: Nick Livens > Attachments: nuageVspMarvinLogs.tar.gz > > > Nuage VSP 3.2 is being released, we want to bring the plugin up to date for > this release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989114#comment-14989114 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1029#issuecomment-153634024 @koushik-das Thanks for your comments. I pushed a new commit . > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9026) Modifying testpath for adding missing parameter
Priti Sarap created CLOUDSTACK-9026: --- Summary: Modifying testpath for adding missing parameter Key: CLOUDSTACK-9026 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9026 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Reporter: Priti Sarap -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6797) volume resize should not be allowed for detached volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989181#comment-14989181 ] Rajani Karuturi commented on CLOUDSTACK-6797: - [~shadowsor], any update on this issue? > volume resize should not be allowed for detached volumes > > > Key: CLOUDSTACK-6797 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6797 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0, 4.4.0 >Reporter: prashant kumar mishra >Assignee: Marcus Sorensen >Priority: Critical > Fix For: Future > > Attachments: Logs_db.rar, screenshot-1.jpg, screenshot-2.jpg > > > =>since resize space is counted in allocated space even though it cant be > attach to VM , other storage operation will fail because threshold value > If resize is allowed in volume detach > == > 1-since there is no check for how much can be increased , suppose user has > resized it to 1000GB > 2-when user try to attach volume to vm it will fail since available space is > not sufficient . > 3-even though user is not able to use the resized volume ,CS will count > 1000GB in allocated storage . > 4-Dash will show allocated percentage >100% > 5-Because threshold values , we cant perform any operation to that PS > If resize is allowed online ( volume Attach) state it will fail in first > place and will not cause any problem -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8746) VM Snapshotting implementation for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989189#comment-14989189 ] ASF GitHub Bot commented on CLOUDSTACK-8746: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/977#issuecomment-153650536 @wido code are updated. I have a node running with Ubuntu 12.04/qemu 1.2.1/libvirt 0.9.13 (not stock QEMU 1.0 and libvirt 0.9.8). It works fine in the vm snapshot testing. I did not test libvirt 0.9.8, but I think it will work. I will test it. > VM Snapshotting implementation for KVM > -- > > Key: CLOUDSTACK-8746 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8746 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > Currently it is not supported. > https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9026) Modifying testpath for adding missing parameter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989190#comment-14989190 ] ASF GitHub Bot commented on CLOUDSTACK-9026: GitHub user pritisarap12 opened a pull request: https://github.com/apache/cloudstack/pull/1031 CLOUDSTACK-9026: Modifying testpath for adding missing parameter Addning service_offering creation in testpath_storage_migration.py testpath which is missing right now You can merge this pull request into a Git repository by running: $ git pull https://github.com/pritisarap12/cloudstack CLOUDSTACK-9026-Modifying-testpath-for-adding-missing-parameter Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1031.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 #1031 commit c2376334592835c30b865c2b08f8c179eed8d328 Author: Priti Sarap Date: 2015-11-04T09:18:38Z CLOUDSTACK-9026: Modifying testpath for adding missing parameter > Modifying testpath for adding missing parameter > --- > > Key: CLOUDSTACK-9026 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9026 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989199#comment-14989199 ] ASF GitHub Bot commented on CLOUDSTACK-8925: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1023#issuecomment-153656222 Talked with @karuturi and agreed that we make the tests in this PR work, then merge it. The other issue should be tracked and fixed separately as it is not a blocker (and this PR fixes a blocker). > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989212#comment-14989212
]
ASF GitHub Bot commented on CLOUDSTACK-8715:
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/1027#issuecomment-153664020
ran the regression set with some f
```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 \
component/test_password_server.py \
component/test_router_dhcphosts.py \
smoke/test_loadbalance.py \
smoke/test_internal_lb.py \
smoke/test_ssvm.py \
smoke/test_network.py```
results:
```
Create a redundant VPC with two networks with two VMs in each network ...
=== TestName: test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Status :
SUCCESS ===
ok
Create a redundant VPC with two networks with two VMs in each network and
check default routes ... === TestName: test_02_redundant_VPC_default_routes |
Status : SUCCESS ===
ok
Test iptables default INPUT/FORWARD policy on RouterVM ... === TestName:
test_02_routervm_iptables_policies | Status : SUCCESS ===
ok
Test iptables default INPUT/FORWARD policies on VPC router ... ===
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Stop existing router, add a PF rule and check we can access the VM ... ===
TestName: test_isolate_network_FW_PF_default_routes | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_RVR_Network_FW_PF_SSH_default_routes | 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
=== TestName: test_assign_and_removal_lb | Status : EXCEPTION ===
ERROR
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status :
FAILED ===
FAIL
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 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
==
ERROR: test suite for
--
Traceback (most recent call last):
File
"/usr/lib/python2.7/site-packages/nose-1.3.7-py2.7.egg/nose/suite.py", line
209, in run
self.setUp()
File
"/usr/lib/python2.7/site-packages/nose-1.3.7-py2.7.egg/nose/suite.py", line
2
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989219#comment-14989219 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/1027#issuecomment-153664875 @ustcweizhou I don't see the difference personally, as a admin you already have full access to the Instance if you want to. But this PR conflicts with mine, they can't be merged both :) > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989230#comment-14989230 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user sspans commented on the pull request: https://github.com/apache/cloudstack/pull/1027#issuecomment-153667126 Consistent Snapshots are not possible without freeze/thaw via the guest-agent. I think most people want good snapshots of their virtual machines. That said it's quite possible to disable the agent on particularly sensitive VM's if one feels the need, the channel will still be open but nobody will be listening > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989235#comment-14989235 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/1027#issuecomment-153667850 @sspans Indeed. Users can stop/disable the agent or even block specific commands if they wish to. As CloudStack we don't control what's in the Instance, so it's the user who decides if he/she wants the Agent or not. > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- 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=14989232#comment-14989232 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-153667726 @koushik-das I think it's inappropriate as we're not marking those fields to note that they have hold sensitive information; but anyway that works > 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,
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989237#comment-14989237 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/1027#issuecomment-153668057 So I wrote #985 which adds a channel by default to all guests. The question is, how do we proceed. Which one goes in? > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989236#comment-14989236 ] ASF GitHub Bot commented on CLOUDSTACK-9025: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1030#issuecomment-153668049 I am not sure why this PR is marked blocker/critical. The implemented code is a nested. It should have been a factored out check-method with unit test, not withstanding the integration test instructions in it. > Unable to deploy VM instance from template if template spin from linked clone > snapshot > -- > > Key: CLOUDSTACK-9025 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9025 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.2 > Environment: XenServer 6.5 >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > Fix For: 4.6.0 > > > As default, CloudStack create linked clone snapshot for VM instance . When we > take a snapshot for the VM, and create a template based on such snapshot, > CloudStack only download incremental VHD as template file, as a result, the > VM instance fail to deploy as it is incomplete. -- 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=14989240#comment-14989240
]
ASF GitHub Bot commented on CLOUDSTACK-8485:
Github user bhaisaab commented on the pull request:
https://github.com/apache/cloudstack/pull/1021#issuecomment-153668149
Also, it is possible to avoid serializing the objects by hand (like
adding/appending {, >, <, } etc by hand?). Probably use any available library,
and if that's not possible write unit tests to do some crud like comparisons?
> 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
[jira] [Commented] (CLOUDSTACK-8832) Update Nuage VSP plugin to work with Nuage VSP release 3.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989243#comment-14989243 ] ASF GitHub Bot commented on CLOUDSTACK-8832: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/801#issuecomment-153669186 @runseb, yes in principle but we have a list of 4.7 candidates allready, so It would cantain a little more. Let's try to contain it though. > Update Nuage VSP plugin to work with Nuage VSP release 3.2 > -- > > Key: CLOUDSTACK-8832 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8832 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Nick Livens >Assignee: Nick Livens > Attachments: nuageVspMarvinLogs.tar.gz > > > Nuage VSP 3.2 is being released, we want to bring the plugin up to date for > this release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989245#comment-14989245 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/1029#issuecomment-153669733 Seems good! Great to see this :) Some tests are failing though, could you look into that? > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9027) In the default egress allow network with existing egress rules to block traffic, restarting the network breaks the egress rules
Rajani Karuturi created CLOUDSTACK-9027: --- Summary: In the default egress allow network with existing egress rules to block traffic, restarting the network breaks the egress rules Key: CLOUDSTACK-9027 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9027 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.6.0 Reporter: Rajani Karuturi Priority: Critical This is found while testing PR #1023 https://github.com/apache/cloudstack/pull/1023#issuecomment-153605360 In the default egress allow network, it has an existing egress rule(created earlier from egress tab on network page) to block port 22 and restarting it created a new router without egress chain on the VR. when I deleted the rule(from the egress tab on network page) and restarted network, it created new router with egress chain properly configured in the iptables. to clear the confusion, I was able to reproduce it with the following steps 1. create a new network with default egress allow (network name: egress2_allow) 2. launch a vm in the network. 3. check that VR came up and running 4. ssh to VR and check the iptables. 5. verified that iptables FW_EGRESS_RULES chain is present and configured properly. 6. test outgoing traffic from user vm created in this network. (ssh and ping were working fine) 7. create a egress rule to block port 22 (from the egress rules tab on networks page in UI) 8. verified that iptables drop rule is added in FW_EGRESS_RULES chain on VR 9. verified that ssh from user vm doesnt work 10. restart network and wait till a new VR is created and running 11. observe that FW_EGRESS_RULES chain is missing in the iptables on the new VR 12. also, ping google.com and ssh doesnt work from user vm -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989252#comment-14989252 ] ASF GitHub Bot commented on CLOUDSTACK-8925: Github user karuturi commented on the pull request: https://github.com/apache/cloudstack/pull/1023#issuecomment-153671338 I created https://issues.apache.org/jira/browse/CLOUDSTACK-9027 to track the new issue > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989260#comment-14989260 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1027#issuecomment-153672795 @wido this PR already includes your commits in #985 > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989268#comment-14989268 ] ASF GitHub Bot commented on CLOUDSTACK-8925: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1023#issuecomment-153673995 Thanks, @karuturi ! I already found the error in the test, running it now and will push the code. The problem was: * For RVR networks, an extra pub IP is being acquired, but when I do the SSH it first does a list IPs and uses the first one. In the RVR_default_allow it was not like that. I know: stupid error. Probably due to writing tests after midnight... not healthy and not productive. Cheers, Wilder > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989272#comment-14989272 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/1027#issuecomment-153674330 @ustcweizhou Ah, I see indeed. So the discussion is: - Do we enable the port by default? I would say yes. (Less code!) - Do we enable the port for SSVMs? I would say yes (Easier control over SSVMs) - Do we need Python? I would say no, this can be done from Java > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- 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=14989286#comment-14989286 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-153677208 @bhaisaab can you explain ? I like your comment about the annotation not being descriptive on the sensitivity of the field. So for the best solution we would have to write another annotation for that. It would be tchnical similar to the @LogLevel and the paramter of the @APICommand. thoughts? > 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_addres
[jira] [Commented] (CLOUDSTACK-8902) Restart Network fails in EIP/ELB zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989293#comment-14989293 ] ASF GitHub Bot commented on CLOUDSTACK-8902: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/898 > Restart Network fails in EIP/ELB zone > - > > Key: CLOUDSTACK-8902 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8902 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > > Environment: Basic XS Zone with EIP/LB. > In an EIP zone, restarting a network with cleanup option checked , is failing > with NumberFormatException. > 2015-07-13 10:52:29,819 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (API-Job-Executor-52:ctx-c6499039 job-100 ctx-4281c3af) (logid:7b32a53a) > Sending network shutdown to Netscaler > 2015-07-13 10:52:29,825 WARN [o.a.c.e.o.NetworkOrchestrator] > (API-Job-Executor-52:ctx-c6499039 job-100 ctx-4281c3af) (logid:7b32a53a) > Unable to complete shutdown of the network elements due to element: Netscaler > java.lang.NumberFormatException: For input string: "untagged" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > at java.lang.Long.parseLong(Long.java:441) > at java.lang.Long.parseLong(Long.java:483) > at > com.cloud.network.ExternalLoadBalancerDeviceManagerImpl.manageGuestNetworkWithExternalLoadBalancer(ExternalLoadBalancerDeviceManagerImpl.java:1013) > at > com.cloud.network.element.NetscalerElement.shutdown(NetscalerElement.java:223) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.shutdownNetworkElementsAndResources(NetworkOrchestrator.java:2251) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2553) > at > com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1910) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy164.restartNetwork(Unknown Source) > at > org.apache.cloudstack.api.command.user.network.RestartNetworkCmd.execute(RestartNetworkCmd.java:95) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:132) > at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:549) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:500) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecu
[jira] [Commented] (CLOUDSTACK-8902) Restart Network fails in EIP/ELB zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989292#comment-14989292 ] ASF subversion and git services commented on CLOUDSTACK-8902: - Commit 2fd6fac214956693b43dd3e75b6d8a4bc4e9fdc6 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2fd6fac ] Merge pull request #898 from bvbharatk/CLOUDSTACK-8902 CLOUDSTACK-8902 Restart Network fails in EIP/ELB zoneThe restart network was failing when using external loadbalencer. The failure was because of a number format exception. When BroadcastDomainType.getValue(guestConfig.getBroadcastUri() is executed this returns a string untagged. We were trying to parse this as long so there was a number pointer exception. This happens only when the vlan uri is vlan://untagged. in other cases were there is a number instead of untagged (vlan tag) this used to succeed. Although we were trying to convert the number to long we were not really using it. we were converting the number to long and then back to string when creating the IpAddressTo. so I removed this unnecessary conversion in this case for fixing the issue at hand. I did a manual restart of the network and checked for this number format exception in a EIP/ELB setup. * pr/898: CLOUDSTACK-89027 Restart Network fails in EIP/ELB zone Signed-off-by: Remi Bergsma > Restart Network fails in EIP/ELB zone > - > > Key: CLOUDSTACK-8902 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8902 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > > Environment: Basic XS Zone with EIP/LB. > In an EIP zone, restarting a network with cleanup option checked , is failing > with NumberFormatException. > 2015-07-13 10:52:29,819 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (API-Job-Executor-52:ctx-c6499039 job-100 ctx-4281c3af) (logid:7b32a53a) > Sending network shutdown to Netscaler > 2015-07-13 10:52:29,825 WARN [o.a.c.e.o.NetworkOrchestrator] > (API-Job-Executor-52:ctx-c6499039 job-100 ctx-4281c3af) (logid:7b32a53a) > Unable to complete shutdown of the network elements due to element: Netscaler > java.lang.NumberFormatException: For input string: "untagged" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > at java.lang.Long.parseLong(Long.java:441) > at java.lang.Long.parseLong(Long.java:483) > at > com.cloud.network.ExternalLoadBalancerDeviceManagerImpl.manageGuestNetworkWithExternalLoadBalancer(ExternalLoadBalancerDeviceManagerImpl.java:1013) > at > com.cloud.network.element.NetscalerElement.shutdown(NetscalerElement.java:223) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.shutdownNetworkElementsAndResources(NetworkOrchestrator.java:2251) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2553) > at > com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1910) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy164.restartNetwork(Unknown Source) > at > org.apache.cloudstack.api.command.user.network.RestartNetworkCmd.execute(RestartNetworkCmd.java:95) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java
[jira] [Commented] (CLOUDSTACK-8902) Restart Network fails in EIP/ELB zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989291#comment-14989291 ] ASF subversion and git services commented on CLOUDSTACK-8902: - Commit 2fd6fac214956693b43dd3e75b6d8a4bc4e9fdc6 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2fd6fac ] Merge pull request #898 from bvbharatk/CLOUDSTACK-8902 CLOUDSTACK-8902 Restart Network fails in EIP/ELB zoneThe restart network was failing when using external loadbalencer. The failure was because of a number format exception. When BroadcastDomainType.getValue(guestConfig.getBroadcastUri() is executed this returns a string untagged. We were trying to parse this as long so there was a number pointer exception. This happens only when the vlan uri is vlan://untagged. in other cases were there is a number instead of untagged (vlan tag) this used to succeed. Although we were trying to convert the number to long we were not really using it. we were converting the number to long and then back to string when creating the IpAddressTo. so I removed this unnecessary conversion in this case for fixing the issue at hand. I did a manual restart of the network and checked for this number format exception in a EIP/ELB setup. * pr/898: CLOUDSTACK-89027 Restart Network fails in EIP/ELB zone Signed-off-by: Remi Bergsma > Restart Network fails in EIP/ELB zone > - > > Key: CLOUDSTACK-8902 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8902 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > > Environment: Basic XS Zone with EIP/LB. > In an EIP zone, restarting a network with cleanup option checked , is failing > with NumberFormatException. > 2015-07-13 10:52:29,819 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (API-Job-Executor-52:ctx-c6499039 job-100 ctx-4281c3af) (logid:7b32a53a) > Sending network shutdown to Netscaler > 2015-07-13 10:52:29,825 WARN [o.a.c.e.o.NetworkOrchestrator] > (API-Job-Executor-52:ctx-c6499039 job-100 ctx-4281c3af) (logid:7b32a53a) > Unable to complete shutdown of the network elements due to element: Netscaler > java.lang.NumberFormatException: For input string: "untagged" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > at java.lang.Long.parseLong(Long.java:441) > at java.lang.Long.parseLong(Long.java:483) > at > com.cloud.network.ExternalLoadBalancerDeviceManagerImpl.manageGuestNetworkWithExternalLoadBalancer(ExternalLoadBalancerDeviceManagerImpl.java:1013) > at > com.cloud.network.element.NetscalerElement.shutdown(NetscalerElement.java:223) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.shutdownNetworkElementsAndResources(NetworkOrchestrator.java:2251) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2553) > at > com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1910) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy164.restartNetwork(Unknown Source) > at > org.apache.cloudstack.api.command.user.network.RestartNetworkCmd.execute(RestartNetworkCmd.java:95) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989300#comment-14989300 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1029#issuecomment-153680788 LGTM +1 (just code review, no testing was performed) > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989301#comment-14989301 ] ASF GitHub Bot commented on CLOUDSTACK-8925: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1023#issuecomment-153681147 Glad you found it @wilderrodrigues and thanks for the fix! Will retest soon! > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9006) ListTemplates API returns result in inconsistent order when called concurrently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989305#comment-14989305 ] ASF GitHub Bot commented on CLOUDSTACK-9006: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1009#issuecomment-153681458 code LGTM, @rags22489664 can you put the integration test in the simulator on your backlog? would love to see it :) If tests pass merge, @remibergsma . Thought the only commit since your tests is the unit test which is validated by jenkins so merge at your will actually. > ListTemplates API returns result in inconsistent order when called > concurrently > --- > > Key: CLOUDSTACK-9006 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9006 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Ramamurti Subramanian >Assignee: Ramamurti Subramanian > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989304#comment-14989304 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1027#issuecomment-153681436 @wido @sspans To be honest, this code was written by me about two years ago , which is not used for now. I created the PR because you guys can judge this code are useful or not. I have no comments if we revert some of the commits (or even all). 1. for the default port, if most of you agree, I will revert the related commits. 2. I agree. I did not remove it in the commits. However, I change the 'vmName'.vport as the first virtio port, because cloud-early-config get the publickey and boot args from /dev/vport0p1. 3. rom my point of view, python is easy for testing, the data send/receive are already implemented. If you want to replace it with Java, that's very good. for now, python works fine in my testing, I even use it for guest agent command testing. btw, do you want replace patachviasocket.pl with java ? I replace it with the python script in the PR. > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- 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=14989307#comment-14989307 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-153681687 @DaanHoogland we can simply use @LogLevel I simply shared that there is a slight chance on confusion in future, and do we then remove the requestHasSensitiveInfo/responseHasSensitiveInfo from Param/Apis throughout the codebase? > 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_
[jira] [Commented] (CLOUDSTACK-9006) ListTemplates API returns result in inconsistent order when called concurrently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989311#comment-14989311 ] ASF subversion and git services commented on CLOUDSTACK-9006: - Commit 9d1a469ae5f0a3751b64d66582fbcc2180a9c97c in cloudstack's branch refs/heads/master from [~ramamurtis] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9d1a469 ] CLOUDSTACK-9006 - ListTemplates API returns result in inconsistent order when called concurrently Adding filter test to verify addOrderBy method. > ListTemplates API returns result in inconsistent order when called > concurrently > --- > > Key: CLOUDSTACK-9006 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9006 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Ramamurti Subramanian >Assignee: Ramamurti Subramanian > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9006) ListTemplates API returns result in inconsistent order when called concurrently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989314#comment-14989314 ] ASF subversion and git services commented on CLOUDSTACK-9006: - Commit 5f610415504b9f18f91169761598a1585ce429c7 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5f61041 ] Merge pull request #1009 from rags22489664/master CLOUDSTACK-9006 - ListTemplates API returns result in inconsistent order when called concurrentlyThe order of templates returned in the response is based on a field called sortkey and by default value for the field is set to 0. With more than 1000 templates, we tried listing the templates with different page sizes concurrently, and we noticed the results being inconsistent. Thus we added a secondary order by clause to list templates call on tempZonePair column to make sure the results are consistent. The addOrderby method of Filter class was also not appending , if we added more orderby clauses. * pr/1009: CLOUDSTACK-9006 - ListTemplates API returns result in inconsistent order when called concurrently CLOUDSTACK-9006 - ListTemplates API returns result in inconsistent order when called concurrently Signed-off-by: Remi Bergsma > ListTemplates API returns result in inconsistent order when called > concurrently > --- > > Key: CLOUDSTACK-9006 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9006 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Ramamurti Subramanian >Assignee: Ramamurti Subramanian > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9012) coreos test case automation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989316#comment-14989316 ] ASF GitHub Bot commented on CLOUDSTACK-9012: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1011#issuecomment-153681911 LGTM (not tested, just reviewed code) > coreos test case automation > --- > > Key: CLOUDSTACK-9012 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9012 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: shweta agarwal > > Automated a full scenario of coreos guest OS support: > it includes registering coreos templates present at > http://dl.openvm.eu/cloudstack/coreos/x86_64/ > 1. based on hypervisor types of zone > 2. creating ssh key pair > 3. creating a sample user data > 4. creating a coreos virtual machine using this ssh keypair and userdata > 5. verifying ssh access to coreo os machine using keypair and core username > 6. verifying userdata is applied on virtual machine and the service asked in > sample data is actually running > 7. Verifying userdata in router vm as well -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9006) ListTemplates API returns result in inconsistent order when called concurrently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989313#comment-14989313 ] ASF subversion and git services commented on CLOUDSTACK-9006: - Commit 5f610415504b9f18f91169761598a1585ce429c7 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5f61041 ] Merge pull request #1009 from rags22489664/master CLOUDSTACK-9006 - ListTemplates API returns result in inconsistent order when called concurrentlyThe order of templates returned in the response is based on a field called sortkey and by default value for the field is set to 0. With more than 1000 templates, we tried listing the templates with different page sizes concurrently, and we noticed the results being inconsistent. Thus we added a secondary order by clause to list templates call on tempZonePair column to make sure the results are consistent. The addOrderby method of Filter class was also not appending , if we added more orderby clauses. * pr/1009: CLOUDSTACK-9006 - ListTemplates API returns result in inconsistent order when called concurrently CLOUDSTACK-9006 - ListTemplates API returns result in inconsistent order when called concurrently Signed-off-by: Remi Bergsma > ListTemplates API returns result in inconsistent order when called > concurrently > --- > > Key: CLOUDSTACK-9006 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9006 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Ramamurti Subramanian >Assignee: Ramamurti Subramanian > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9006) ListTemplates API returns result in inconsistent order when called concurrently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989315#comment-14989315 ] ASF GitHub Bot commented on CLOUDSTACK-9006: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1009 > ListTemplates API returns result in inconsistent order when called > concurrently > --- > > Key: CLOUDSTACK-9006 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9006 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Ramamurti Subramanian >Assignee: Ramamurti Subramanian > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9006) ListTemplates API returns result in inconsistent order when called concurrently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989310#comment-14989310 ] ASF subversion and git services commented on CLOUDSTACK-9006: - Commit c90723f491c8da4cb9873a896a2410f60b358193 in cloudstack's branch refs/heads/master from [~ramamurtis] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c90723f ] CLOUDSTACK-9006 - ListTemplates API returns result in inconsistent order when called concurrently > ListTemplates API returns result in inconsistent order when called > concurrently > --- > > Key: CLOUDSTACK-9006 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9006 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Ramamurti Subramanian >Assignee: Ramamurti Subramanian > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9006) ListTemplates API returns result in inconsistent order when called concurrently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989312#comment-14989312 ] ASF subversion and git services commented on CLOUDSTACK-9006: - Commit 5f610415504b9f18f91169761598a1585ce429c7 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5f61041 ] Merge pull request #1009 from rags22489664/master CLOUDSTACK-9006 - ListTemplates API returns result in inconsistent order when called concurrentlyThe order of templates returned in the response is based on a field called sortkey and by default value for the field is set to 0. With more than 1000 templates, we tried listing the templates with different page sizes concurrently, and we noticed the results being inconsistent. Thus we added a secondary order by clause to list templates call on tempZonePair column to make sure the results are consistent. The addOrderby method of Filter class was also not appending , if we added more orderby clauses. * pr/1009: CLOUDSTACK-9006 - ListTemplates API returns result in inconsistent order when called concurrently CLOUDSTACK-9006 - ListTemplates API returns result in inconsistent order when called concurrently Signed-off-by: Remi Bergsma > ListTemplates API returns result in inconsistent order when called > concurrently > --- > > Key: CLOUDSTACK-9006 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9006 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Ramamurti Subramanian >Assignee: Ramamurti Subramanian > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8996) Reducing Virual Machine Deployments
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989319#comment-14989319 ] ASF GitHub Bot commented on CLOUDSTACK-8996: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1010#issuecomment-153682260 @pritisarap12 I don't see any changes on the "Files changed" tab is the file plaintext with 0644 file mod, or is it already merged on master? > Reducing Virual Machine Deployments > --- > > Key: CLOUDSTACK-8996 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8996 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > Combining testcases to reduce the VM deployments wherever possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8996) Reducing Virual Machine Deployments
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989323#comment-14989323 ] ASF GitHub Bot commented on CLOUDSTACK-8996: Github user borisroman commented on the pull request: https://github.com/apache/cloudstack/pull/1010#issuecomment-153682641 @bhaisaab It's a new file with more then 2k lines, so github doesn't show it right away. Though if you click on view you can see it. https://github.com/pritisarap12/cloudstack/blob/CLOUDSTACK-8996-Reducing-Virual-Machine-Deployments/test/integration/testpaths/testpath_reduce_vm_deployments.py > Reducing Virual Machine Deployments > --- > > Key: CLOUDSTACK-8996 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8996 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > Combining testcases to reduce the VM deployments wherever possible. -- 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=14989322#comment-14989322
]
ASF GitHub Bot commented on CLOUDSTACK-8485:
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/1021#issuecomment-153682474
@bhaisaab no we shouldn't remove those both are used. I didn't understand
the {, <, >, } part.
The @LogLevel is used in the gson serialization and we can abuse it in the
API but your comment makes sense. In the meanwhile that doesn't invalidate
Koushik's change.
let's make the right decision
> listAPIs are taking too long to return results
> --
>
> Key: CLOUDSTACK-8485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.5.1, 4.6.0
>Reporter: Sowmya Krishnan
>Assignee: Koushik Das
> Fix For: 4.6.0
>
>
> listAPIs are taking significantly longer than before (4.2.x)
> I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K
> Routers. Here are few results:
> listVirtualMachines is taking > 25 sec to return with pagesize set to 50.
> This is in comparison to 2 sec in earlier cases such as 4.2.
> listVolumes with pagesize = 1000 took more than 10 mins and finally times out.
> Further observations show that there are also lot of slow queries being
> logged in catalina.out and in MySQL slow query logs. I am not sure if this
> could be the reason for DB performance getting impacted in turn causing an
> impact on listAPIs too.
> Here's a sample of slow queries from catalina.out:
> Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 3305 ms, connection-id: 637759, statement-id: 3218312,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305
> ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name,
> user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE
> user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler
> Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 3305 ms, connection-id: 637843, statement-id: 3218311,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type,
> host.private_ip_address, host.private_mac_address, host.private_netmask,
> host.public_netmask, host.public_ip_address, host.public_mac_address,
> host.storage_ip_address, host.cluster_id, host.storage_netmask,
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2,
> host.storage_mac_address_2, host.hypervisor_type, host.proxy_port,
> host.resource, host.fs_type, host.available, host.setup, host.resource_state,
> host.hypervisor_version, host.update_count, host.uuid, host.data_center_id,
> host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram,
> host.parent, host.guid, host.capabilities, host.total_size, host.last_ping,
> host.mgmt_server_id, host.dom0_memory, host.version, host.created,
> host.removed FROM host WHERE host.id = 345 AND host.removed IS NULL
> Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 6458 ms, connection-id: 637623, statement-id: 3218243,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458
> ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref INNER
> JOIN host ON storage_pool_host_ref.host_id=host.id WHERE
> storage_pool_host_ref.pool_id = 197 AND (host.status = 'Up' AND
> host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler
> Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 2402 ms, connection-id: 637754, statement-id: 3218371,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type,
> host.private_ip_address, host.private_mac_address, host.private_netmask,
> host.public_netmask, host.public_ip_address, host.public_mac_address,
> host.storage_ip_address, host.cluster_id, host.storage_netmask,
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2,
> host.
[jira] [Commented] (CLOUDSTACK-9006) ListTemplates API returns result in inconsistent order when called concurrently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989326#comment-14989326 ] ASF subversion and git services commented on CLOUDSTACK-9006: - Commit 4e6ff4b3c3d16a68127db5a642c5875a12c51b9e in cloudstack's branch refs/heads/4.5 from [~ramamurtis] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4e6ff4b ] CLOUDSTACK-9006 - ListTemplates API returns result in inconsistent order when called concurrently (cherry picked from commit c90723f491c8da4cb9873a896a2410f60b358193) Signed-off-by: Rohit Yadav > ListTemplates API returns result in inconsistent order when called > concurrently > --- > > Key: CLOUDSTACK-9006 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9006 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Ramamurti Subramanian >Assignee: Ramamurti Subramanian > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9006) ListTemplates API returns result in inconsistent order when called concurrently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989327#comment-14989327 ] ASF subversion and git services commented on CLOUDSTACK-9006: - Commit efe93d7487d0f79394f31ea75425e33039e858f5 in cloudstack's branch refs/heads/4.5 from [~ramamurtis] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=efe93d7 ] CLOUDSTACK-9006 - ListTemplates API returns result in inconsistent order when called concurrently Adding filter test to verify addOrderBy method. (cherry picked from commit 9d1a469ae5f0a3751b64d66582fbcc2180a9c97c) Signed-off-by: Rohit Yadav > ListTemplates API returns result in inconsistent order when called > concurrently > --- > > Key: CLOUDSTACK-9006 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9006 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Ramamurti Subramanian >Assignee: Ramamurti Subramanian > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9005) Modifying tearDown function
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989331#comment-14989331 ] ASF GitHub Bot commented on CLOUDSTACK-9005: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1000#issuecomment-153683247 LGTM > Modifying tearDown function > > > Key: CLOUDSTACK-9005 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9005 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > Modifying tearDown function to check if data volume is in detached state > before deleting the volume -- 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=14989330#comment-14989330 ] ASF GitHub Bot commented on CLOUDSTACK-8958: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1007#issuecomment-153683174 LGTM > 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-8970) Centos 6.{1,2,3,4,5} guest OS mapping for vmware is not available
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989337#comment-14989337
]
ASF GitHub Bot commented on CLOUDSTACK-8970:
Github user bhaisaab commented on the pull request:
https://github.com/apache/cloudstack/pull/956#issuecomment-153684702
LGTM, @abhinandanprateek do you have any comments?
> Centos 6.{1,2,3,4,5} guest OS mapping for vmware is not available
> -
>
> Key: CLOUDSTACK-8970
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8970
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: sudharma jain
>
> "Dynamically Scale" fails everytime because the setting of the guest OS in
> VMware is not correctly set. When we set the OS Type of a
> VM(account1-centos1) to "CentOS 6.5 (64-bit)". Then the value of the guest OS
> in VMware is set to "Other (64-bit) and memory size is displayed by a grayed
> out.
> If the OS type of VM is "CentOS 6.4 (64-bit)" , "CentOS 6.3 (64-bit)"
> ,"CentOS 6.2 (64-bit)" or "CentOS 6.1 (64-bit)", the same issue happen.
> However, for "CentOS 6.0 (64-bit)", the value of the guest OS in VMware is
> set to "Linux CentOS4/5/6/7(64-bit)" and memory size is not displayed by a
> grayed out, we were able to "Dynamically Scale" the VM.
--
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=14989340#comment-14989340 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user koushik-das commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-153686114 @DaanHoogland @bhaisaab requestHasSensitiveInfo/responseHasSensitiveInfo can be removed once this PR is accepted. I don't see any other use of these parameters. > listAPIs are taking too long to return results > -- > > Key: CLOUDSTACK-8485 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.1, 4.6.0 >Reporter: Sowmya Krishnan >Assignee: Koushik Das > Fix For: 4.6.0 > > > listAPIs are taking significantly longer than before (4.2.x) > I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K > Routers. Here are few results: > listVirtualMachines is taking > 25 sec to return with pagesize set to 50. > This is in comparison to 2 sec in earlier cases such as 4.2. > listVolumes with pagesize = 1000 took more than 10 mins and finally times out. > Further observations show that there are also lot of slow queries being > logged in catalina.out and in MySQL slow query logs. I am not sure if this > could be the reason for DB performance getting impacted in turn causing an > impact on listAPIs too. > Here's a sample of slow queries from catalina.out: > Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637759, statement-id: 3218312, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, > user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE > user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637843, statement-id: 3218311, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, > host.resource, host.fs_type, host.available, host.setup, host.resource_state, > host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, > host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, > host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, > host.mgmt_server_id, host.dom0_memory, host.version, host.created, > host.removed FROM host WHERE host.id = 345 AND host.removed IS NULL > Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 6458 ms, connection-id: 637623, statement-id: 3218243, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 > ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref INNER > JOIN host ON storage_pool_host_ref.host_id=host.id WHERE > storage_pool_host_ref.pool_id = 197 AND (host.status = 'Up' AND > host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 2402 ms, connection-id: 637754, statement-id: 3218371, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, > host.resource, host.fs_type, host.available, host.setup, host.resource_state, > host.hy
[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989341#comment-14989341 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-153686801 @koushik-das You don't agree that the name LogLevel obfuscates that it is used to hide sensitive data? > 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_
[jira] [Commented] (CLOUDSTACK-8976) Sorting of security groups
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989343#comment-14989343 ] ASF GitHub Bot commented on CLOUDSTACK-8976: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/937#issuecomment-153686857 LGTM > Sorting of security groups > -- > > Key: CLOUDSTACK-8976 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8976 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.2 >Reporter: CS User >Priority: Minor > Fix For: Future > > > Within the instance creation wizard, when using a basic zone with a large > number of security groups, it can be difficult for the user to select the > required group when presented with a long list. > Currently the list not ordered. It would be better if the groups were sorted > alphabetically. -- 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=14989349#comment-14989349 ] ASF GitHub Bot commented on CLOUDSTACK-8951: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/929#issuecomment-153688096 LGTM > 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-8950) Hypervisor Parameter check is not performed for registerTemplate and getUploadParamsForTemplate API's.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989350#comment-14989350 ] ASF GitHub Bot commented on CLOUDSTACK-8950: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/928#issuecomment-153688197 LGTM (just code review, no testing performed) > Hypervisor Parameter check is not performed for registerTemplate and > getUploadParamsForTemplate API's. > --- > > Key: CLOUDSTACK-8950 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8950 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > Fix For: 4.7.0 > > > Register Template : > http://10.220.135.31:8096/client/api?command=registerTemplate&displaytext=urlapi&format=VHD&hypervisor=ABC&name=urlapi1&ostypeid=6c590b5c-fde9-11e4-b65a-a20b7b72c771&url=http://10.147.28.7/templates/rajani-thin-volume.vhd&zoneid=1e7bbab9-02cd-4067-99f9-3f8b115304df > getUploadParamsForTemplate : > http://10.81.29.49:8096/client/api?command=getUploadParamsForTemplate&type=template&response=json&name=nossvm&displayText=nossvmnossvm&zoneid=ca8adf51-539d-45eb-b205-792a58503d14&format=VHD&isextractable=false&passwordEnabled=false&isdynamicallyscalable=false&osTypeId=ce099056-ee53-11e4-a8ad-d242118f6f9b&hypervisor=XEN&requireshvm=false&apiKey=_cMgYFGzeE0QEMmqN5OWC5QpOm33UqGpVbAXUntbR_ESNoKX-N9TMNhCcl-lUbyYhT90k53gCkvSP0ZO3CWtxg&account=admin&domainid=cddff412-ee53-11e4-a8ad-d242118f6f9b > In the above API calls have given the hypervisor types as ABC and XEN > respectively. No error is thrown and templates are sucessfully registerd and > Uploaded . But they do not list in the Templates section as DB entry for the > above shows HYpervisor as NONE . > Expected Result : > Hypervisor parameter should only accept values which the cloudstack currently > supports and API should fail if we give any other values . Templates should > not be uploaded for NONE type . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8924) [Blocker] test duplicated in test_scale_vm.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989354#comment-14989354
]
ASF GitHub Bot commented on CLOUDSTACK-8924:
Github user karuturi commented on the pull request:
https://github.com/apache/cloudstack/pull/902#issuecomment-153688607
Simple configuration change. Code LGTM
> [Blocker] test duplicated in test_scale_vm.py
> -
>
> Key: CLOUDSTACK-8924
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8924
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
> Fix For: 4.6.0
>
>
> This is a blocker because BVTs for XS and Simulator are failing.
> Simulator zone - it is failing because
> This is a genuine failure - because the setup didn't have Dynamic Scaling
> enabled as part of global settings. Once it is enabled the tests ran fine.
> XS basic/Advzone - it is failing because
> the methods
> test_01_scale_vm(self):
> test_02_scale_vm_without_hypervisor_specifics(self):
> are essentially same with the exception of tags -
> first one - test_01_scale_vm - had a "required_hardware=true"
> second - test_02_scale_vm_without_hypervisor_specific had a
> "required_hardware=false"
> essentially we can get this test run on both Simulator and XenServer by
> modifying the "required_hardware=false".
> and test_02_scale_vm_without_hypervisor_specifc - can be deleted.
> The reason for failure on the XS is due to the following - "Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering"
> Following are the logs:
> Test scale virtual machine ... === TestName: test_01_scale_vm | Status :
> SUCCESS ===
> ok
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm) ... === TestName:
> test_02_scale_vm_without_hypervisor_specifics | Status : EXCEPTION ===
> ERROR
> ==
> ERROR: test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm)
> --
> Traceback (most recent call last):
> File "/root/cloudstack/test/integration/smoke/test_scale_vm.py", line 234,
> in test_02_scale_vm_without_hypervisor_specifics
> self.apiclient.scaleVirtualMachine(cmd)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 797, in scaleVirtualMachine
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created :
> u'2015-09-30T01:16:45+', cmd :
> u'org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin', userid :
> u'd46c0476-670a-11e5-8245-96e5a2a4ae9a', jobstatus : 2, jobid :
> u'ad32dee5-da3c-42c3-bdc3-35928b47697f', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 431, errortext : u'Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering
> (BigInstance)'}, accountid : u'd46bf47c-670a-11e5-8245-96e5a2a4ae9a'}
> >> begin captured stdout << -
> === TestName: test_02_scale_vm_without_hypervisor_specifics | Status :
> EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: STARTED :
> TC: test_02_scale_vm_without_hypervisor_specifics :::
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Payload:
> {'isdynamicallyscalable': 'true', 'apiKey':
> u'FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w',
> 'response': 'json', 'command': 'updateVirtualMachine', 'signature':
> '4dANF6uDGtaOk6jIDb901ES+Oq8=', 'id': u'38c1ced0-693f-4e31-b976-9f4161ac57bb'}
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Sending GET Cmd
> : updateVirtualMachine===
> urllib3.connectionpool: INFO: Starting new HTTP connection (1): 10.220.135.73
> urllib3.connectionpool: DEBUG: "GET
> /client/api?isdynamicallyscalable=true&apiKey=FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w&response=json&command=updateVirtualMachine&signature=4dANF6uDGtaOk6jIDb901ES%2BOq8%3D&id=38c1ced0-693f-4e
[jira] [Commented] (CLOUDSTACK-7984) Collect network statistics for VMs on shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989357#comment-14989357 ] ASF GitHub Bot commented on CLOUDSTACK-7984: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/926#issuecomment-153688875 LGTM (just code, no testing performed) > Collect network statistics for VMs on shared network > > > Key: CLOUDSTACK-7984 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7984 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Environment: KVM >Reporter: Wei Zhou >Assignee: Wei Zhou > Fix For: 4.6.0 > > > now we get the network usage from virtual router which is only applied on > isolated network. > We need to collect the network statistics for VM nics on shared network. The > data can be fetched from the hypervisor. > Similar to vm disk statistics, I will implement it for KVM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8924) [Blocker] test duplicated in test_scale_vm.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989362#comment-14989362
]
ASF GitHub Bot commented on CLOUDSTACK-8924:
Github user bhaisaab commented on the pull request:
https://github.com/apache/cloudstack/pull/902#issuecomment-153689139
LGTM
> [Blocker] test duplicated in test_scale_vm.py
> -
>
> Key: CLOUDSTACK-8924
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8924
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
> Fix For: 4.6.0
>
>
> This is a blocker because BVTs for XS and Simulator are failing.
> Simulator zone - it is failing because
> This is a genuine failure - because the setup didn't have Dynamic Scaling
> enabled as part of global settings. Once it is enabled the tests ran fine.
> XS basic/Advzone - it is failing because
> the methods
> test_01_scale_vm(self):
> test_02_scale_vm_without_hypervisor_specifics(self):
> are essentially same with the exception of tags -
> first one - test_01_scale_vm - had a "required_hardware=true"
> second - test_02_scale_vm_without_hypervisor_specific had a
> "required_hardware=false"
> essentially we can get this test run on both Simulator and XenServer by
> modifying the "required_hardware=false".
> and test_02_scale_vm_without_hypervisor_specifc - can be deleted.
> The reason for failure on the XS is due to the following - "Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering"
> Following are the logs:
> Test scale virtual machine ... === TestName: test_01_scale_vm | Status :
> SUCCESS ===
> ok
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm) ... === TestName:
> test_02_scale_vm_without_hypervisor_specifics | Status : EXCEPTION ===
> ERROR
> ==
> ERROR: test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm)
> --
> Traceback (most recent call last):
> File "/root/cloudstack/test/integration/smoke/test_scale_vm.py", line 234,
> in test_02_scale_vm_without_hypervisor_specifics
> self.apiclient.scaleVirtualMachine(cmd)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 797, in scaleVirtualMachine
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created :
> u'2015-09-30T01:16:45+', cmd :
> u'org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin', userid :
> u'd46c0476-670a-11e5-8245-96e5a2a4ae9a', jobstatus : 2, jobid :
> u'ad32dee5-da3c-42c3-bdc3-35928b47697f', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 431, errortext : u'Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering
> (BigInstance)'}, accountid : u'd46bf47c-670a-11e5-8245-96e5a2a4ae9a'}
> >> begin captured stdout << -
> === TestName: test_02_scale_vm_without_hypervisor_specifics | Status :
> EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: STARTED :
> TC: test_02_scale_vm_without_hypervisor_specifics :::
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Payload:
> {'isdynamicallyscalable': 'true', 'apiKey':
> u'FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w',
> 'response': 'json', 'command': 'updateVirtualMachine', 'signature':
> '4dANF6uDGtaOk6jIDb901ES+Oq8=', 'id': u'38c1ced0-693f-4e31-b976-9f4161ac57bb'}
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Sending GET Cmd
> : updateVirtualMachine===
> urllib3.connectionpool: INFO: Starting new HTTP connection (1): 10.220.135.73
> urllib3.connectionpool: DEBUG: "GET
> /client/api?isdynamicallyscalable=true&apiKey=FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w&response=json&command=updateVirtualMachine&signature=4dANF6uDGtaOk6jIDb901ES%2BOq8%3D&id=38c1ced0-693f-4e31-b976-9f4161ac57bb
> HTTP/1.1"
[jira] [Commented] (CLOUDSTACK-8996) Reducing Virual Machine Deployments
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989369#comment-14989369 ] ASF GitHub Bot commented on CLOUDSTACK-8996: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1010#issuecomment-153689927 @borisroman cool thanks, weird though as I've seen github show the entire file in some of the previous PRs > Reducing Virual Machine Deployments > --- > > Key: CLOUDSTACK-8996 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8996 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > Combining testcases to reduce the VM deployments wherever possible. -- 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=14989374#comment-14989374 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user koushik-das commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-153690547 @DaanHoogland I think LogLevel is a better/generic name to suppress a field from getting logged. Currently only sensitive field is getting annotated with it. Going forward some non-sensitive field may also be annotated if someone wants to prevent it from getting logged. Also since LogLevel is already used in agent commands, having an uniform approach throughout the code is always better and creates less confusion. > 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, hos
[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=14989375#comment-14989375
]
ASF GitHub Bot commented on CLOUDSTACK-8485:
Github user bhaisaab commented on the pull request:
https://github.com/apache/cloudstack/pull/1021#issuecomment-153690595
@DaanHoogland if you look at the changes or the code that takes in Object
(Response object) and serializes it; we create the json or xml response string
by manually adding the delimiters ({, }, <, >, : characters etc). I was
wondering if there is a way to avoid that.
> 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, hos
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989387#comment-14989387 ] ASF GitHub Bot commented on CLOUDSTACK-8925: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1023#issuecomment-153693746 Ping @remibergsma @karuturi @borisroman @DaanHoogland @miguelaferreira Test is finally done and bug-free! Test Environment: * Hardware required: true * Management Server + MySQL on CentOS 7.1 * One KVM host on CentOS 7.1 * ACS Agent + Common RPMs built from source ``` 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 -- Ran 4 tests in 2085.023s OK /tmp//MarvinLogs/test_routers_network_ops_N14PY8/results.txt (END) ``` Cheers, Wilder > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989392#comment-14989392 ] ASF GitHub Bot commented on CLOUDSTACK-8925: Github user borisroman commented on the pull request: https://github.com/apache/cloudstack/pull/1023#issuecomment-153694220 @wilderrodrigues Running now. > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9027) In the default egress allow network with existing egress rules to block traffic, restarting the network breaks the egress rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wilder Rodrigues reassigned CLOUDSTACK-9027: Assignee: Wilder Rodrigues > In the default egress allow network with existing egress rules to block > traffic, restarting the network breaks the egress rules > --- > > Key: CLOUDSTACK-9027 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9027 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Rajani Karuturi >Assignee: Wilder Rodrigues >Priority: Critical > > This is found while testing PR #1023 > https://github.com/apache/cloudstack/pull/1023#issuecomment-153605360 > In the default egress allow network, it has an existing egress rule(created > earlier from egress tab on network page) to block port 22 and restarting it > created a new router without egress chain on the VR. > when I deleted the rule(from the egress tab on network page) and restarted > network, it created new router with egress chain properly configured in the > iptables. > to clear the confusion, I was able to reproduce it with the following steps > 1. create a new network with default egress allow (network name: > egress2_allow) > 2. launch a vm in the network. > 3. check that VR came up and running > 4. ssh to VR and check the iptables. > 5. verified that iptables FW_EGRESS_RULES chain is present and configured > properly. > 6. test outgoing traffic from user vm created in this network. (ssh and ping > were working fine) > 7. create a egress rule to block port 22 (from the egress rules tab on > networks page in UI) > 8. verified that iptables drop rule is added in FW_EGRESS_RULES chain on VR > 9. verified that ssh from user vm doesnt work > 10. restart network and wait till a new VR is created and running > 11. observe that FW_EGRESS_RULES chain is missing in the iptables on the new > VR > 12. also, ping google.com and ssh doesnt work from user vm -- 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=14989399#comment-14989399 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user koushik-das commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-153695015 @bhaisaab Agree that the existing JSON and XML serialization can be improved but it is better to do it as a separate PR. For JSON, the standard Gson library is used. For XML we may have to check for a ASF compatible library that solves the purpose. > 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,
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989428#comment-14989428 ] ASF GitHub Bot commented on CLOUDSTACK-8925: Github user borisroman commented on the pull request: https://github.com/apache/cloudstack/pull/1023#issuecomment-153699912 @wilderrodrigues @remibergsma Still had the tests setup running. Here are the results: ``` === TestName: test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS === ok === TestName: test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS === ok === TestName: test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS === ok === TestName: test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS === ok ``` LGTM :+1: > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8924) [Blocker] test duplicated in test_scale_vm.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989437#comment-14989437
]
ASF subversion and git services commented on CLOUDSTACK-8924:
-
Commit 2af9611c20530e1e1900acea6e753e9e1ac5acf7 in cloudstack's branch
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2af9611 ]
Merge pull request #902 from sanju1010/simulator
CLOUDSTACK-8924: Enable dynamic scaling to run test_scale_vm.py test on
simulatorSimulator setup uses the config file from following location:
tools/marvin/marvin/config/setup.cfg
Added global setting parameter "enable.dynamic.scale.vm" to above config file,
so that dynamic scale vm tests can be run on simulator.
* pr/902:
CLOUDSTACK-8924: Made changes based on the comments from @pvr9711
Signed-off-by: Remi Bergsma
> [Blocker] test duplicated in test_scale_vm.py
> -
>
> Key: CLOUDSTACK-8924
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8924
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
> Fix For: 4.6.0
>
>
> This is a blocker because BVTs for XS and Simulator are failing.
> Simulator zone - it is failing because
> This is a genuine failure - because the setup didn't have Dynamic Scaling
> enabled as part of global settings. Once it is enabled the tests ran fine.
> XS basic/Advzone - it is failing because
> the methods
> test_01_scale_vm(self):
> test_02_scale_vm_without_hypervisor_specifics(self):
> are essentially same with the exception of tags -
> first one - test_01_scale_vm - had a "required_hardware=true"
> second - test_02_scale_vm_without_hypervisor_specific had a
> "required_hardware=false"
> essentially we can get this test run on both Simulator and XenServer by
> modifying the "required_hardware=false".
> and test_02_scale_vm_without_hypervisor_specifc - can be deleted.
> The reason for failure on the XS is due to the following - "Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering"
> Following are the logs:
> Test scale virtual machine ... === TestName: test_01_scale_vm | Status :
> SUCCESS ===
> ok
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm) ... === TestName:
> test_02_scale_vm_without_hypervisor_specifics | Status : EXCEPTION ===
> ERROR
> ==
> ERROR: test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm)
> --
> Traceback (most recent call last):
> File "/root/cloudstack/test/integration/smoke/test_scale_vm.py", line 234,
> in test_02_scale_vm_without_hypervisor_specifics
> self.apiclient.scaleVirtualMachine(cmd)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 797, in scaleVirtualMachine
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created :
> u'2015-09-30T01:16:45+', cmd :
> u'org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin', userid :
> u'd46c0476-670a-11e5-8245-96e5a2a4ae9a', jobstatus : 2, jobid :
> u'ad32dee5-da3c-42c3-bdc3-35928b47697f', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 431, errortext : u'Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering
> (BigInstance)'}, accountid : u'd46bf47c-670a-11e5-8245-96e5a2a4ae9a'}
> >> begin captured stdout << -
> === TestName: test_02_scale_vm_without_hypervisor_specifics | Status :
> EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: STARTED :
> TC: test_02_scale_vm_without_hypervisor_specifics :::
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Payload:
> {'isdynamicallyscalable': 'true', 'apiKey':
> u'FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w',
> 'response': 'json', 'command': 'updateVirtualMachine', 'signature':
> '4dANF6uDGtaOk6jIDb901ES+Oq8=', 'id': u'38c1ced0-693f-4e31-b976-9f4161ac57bb'}
>
[jira] [Commented] (CLOUDSTACK-8924) [Blocker] test duplicated in test_scale_vm.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989435#comment-14989435
]
ASF subversion and git services commented on CLOUDSTACK-8924:
-
Commit d39c6a0e18f37ffcb60c06a232ff1e0d9f926d03 in cloudstack's branch
refs/heads/master from sanjeev
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d39c6a0 ]
CLOUDSTACK-8924: Made changes based on the comments from @pvr9711
> [Blocker] test duplicated in test_scale_vm.py
> -
>
> Key: CLOUDSTACK-8924
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8924
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
> Fix For: 4.6.0
>
>
> This is a blocker because BVTs for XS and Simulator are failing.
> Simulator zone - it is failing because
> This is a genuine failure - because the setup didn't have Dynamic Scaling
> enabled as part of global settings. Once it is enabled the tests ran fine.
> XS basic/Advzone - it is failing because
> the methods
> test_01_scale_vm(self):
> test_02_scale_vm_without_hypervisor_specifics(self):
> are essentially same with the exception of tags -
> first one - test_01_scale_vm - had a "required_hardware=true"
> second - test_02_scale_vm_without_hypervisor_specific had a
> "required_hardware=false"
> essentially we can get this test run on both Simulator and XenServer by
> modifying the "required_hardware=false".
> and test_02_scale_vm_without_hypervisor_specifc - can be deleted.
> The reason for failure on the XS is due to the following - "Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering"
> Following are the logs:
> Test scale virtual machine ... === TestName: test_01_scale_vm | Status :
> SUCCESS ===
> ok
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm) ... === TestName:
> test_02_scale_vm_without_hypervisor_specifics | Status : EXCEPTION ===
> ERROR
> ==
> ERROR: test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm)
> --
> Traceback (most recent call last):
> File "/root/cloudstack/test/integration/smoke/test_scale_vm.py", line 234,
> in test_02_scale_vm_without_hypervisor_specifics
> self.apiclient.scaleVirtualMachine(cmd)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 797, in scaleVirtualMachine
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created :
> u'2015-09-30T01:16:45+', cmd :
> u'org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin', userid :
> u'd46c0476-670a-11e5-8245-96e5a2a4ae9a', jobstatus : 2, jobid :
> u'ad32dee5-da3c-42c3-bdc3-35928b47697f', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 431, errortext : u'Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering
> (BigInstance)'}, accountid : u'd46bf47c-670a-11e5-8245-96e5a2a4ae9a'}
> >> begin captured stdout << -
> === TestName: test_02_scale_vm_without_hypervisor_specifics | Status :
> EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: STARTED :
> TC: test_02_scale_vm_without_hypervisor_specifics :::
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Payload:
> {'isdynamicallyscalable': 'true', 'apiKey':
> u'FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w',
> 'response': 'json', 'command': 'updateVirtualMachine', 'signature':
> '4dANF6uDGtaOk6jIDb901ES+Oq8=', 'id': u'38c1ced0-693f-4e31-b976-9f4161ac57bb'}
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Sending GET Cmd
> : updateVirtualMachine===
> urllib3.connectionpool: INFO: Starting new HTTP connection (1): 10.220.135.73
> urllib3.connectionpool: DEBUG: "GET
> /client/api?isdynamicallyscalable=true&apiKey=FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w&re
[jira] [Commented] (CLOUDSTACK-8924) [Blocker] test duplicated in test_scale_vm.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989438#comment-14989438
]
ASF GitHub Bot commented on CLOUDSTACK-8924:
Github user asfgit closed the pull request at:
https://github.com/apache/cloudstack/pull/902
> [Blocker] test duplicated in test_scale_vm.py
> -
>
> Key: CLOUDSTACK-8924
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8924
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
> Fix For: 4.6.0
>
>
> This is a blocker because BVTs for XS and Simulator are failing.
> Simulator zone - it is failing because
> This is a genuine failure - because the setup didn't have Dynamic Scaling
> enabled as part of global settings. Once it is enabled the tests ran fine.
> XS basic/Advzone - it is failing because
> the methods
> test_01_scale_vm(self):
> test_02_scale_vm_without_hypervisor_specifics(self):
> are essentially same with the exception of tags -
> first one - test_01_scale_vm - had a "required_hardware=true"
> second - test_02_scale_vm_without_hypervisor_specific had a
> "required_hardware=false"
> essentially we can get this test run on both Simulator and XenServer by
> modifying the "required_hardware=false".
> and test_02_scale_vm_without_hypervisor_specifc - can be deleted.
> The reason for failure on the XS is due to the following - "Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering"
> Following are the logs:
> Test scale virtual machine ... === TestName: test_01_scale_vm | Status :
> SUCCESS ===
> ok
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm) ... === TestName:
> test_02_scale_vm_without_hypervisor_specifics | Status : EXCEPTION ===
> ERROR
> ==
> ERROR: test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm)
> --
> Traceback (most recent call last):
> File "/root/cloudstack/test/integration/smoke/test_scale_vm.py", line 234,
> in test_02_scale_vm_without_hypervisor_specifics
> self.apiclient.scaleVirtualMachine(cmd)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 797, in scaleVirtualMachine
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created :
> u'2015-09-30T01:16:45+', cmd :
> u'org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin', userid :
> u'd46c0476-670a-11e5-8245-96e5a2a4ae9a', jobstatus : 2, jobid :
> u'ad32dee5-da3c-42c3-bdc3-35928b47697f', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 431, errortext : u'Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering
> (BigInstance)'}, accountid : u'd46bf47c-670a-11e5-8245-96e5a2a4ae9a'}
> >> begin captured stdout << -
> === TestName: test_02_scale_vm_without_hypervisor_specifics | Status :
> EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: STARTED :
> TC: test_02_scale_vm_without_hypervisor_specifics :::
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Payload:
> {'isdynamicallyscalable': 'true', 'apiKey':
> u'FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w',
> 'response': 'json', 'command': 'updateVirtualMachine', 'signature':
> '4dANF6uDGtaOk6jIDb901ES+Oq8=', 'id': u'38c1ced0-693f-4e31-b976-9f4161ac57bb'}
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Sending GET Cmd
> : updateVirtualMachine===
> urllib3.connectionpool: INFO: Starting new HTTP connection (1): 10.220.135.73
> urllib3.connectionpool: DEBUG: "GET
> /client/api?isdynamicallyscalable=true&apiKey=FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w&response=json&command=updateVirtualMachine&signature=4dANF6uDGtaOk6jIDb901ES%2BOq8%3D&id=38c1ced0-693f-4e31-b976-9f4161ac57bb
> HTTP/1.1" 200 1703
> test_02_scale_vm_without_hype
[jira] [Commented] (CLOUDSTACK-8924) [Blocker] test duplicated in test_scale_vm.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989436#comment-14989436
]
ASF subversion and git services commented on CLOUDSTACK-8924:
-
Commit 2af9611c20530e1e1900acea6e753e9e1ac5acf7 in cloudstack's branch
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2af9611 ]
Merge pull request #902 from sanju1010/simulator
CLOUDSTACK-8924: Enable dynamic scaling to run test_scale_vm.py test on
simulatorSimulator setup uses the config file from following location:
tools/marvin/marvin/config/setup.cfg
Added global setting parameter "enable.dynamic.scale.vm" to above config file,
so that dynamic scale vm tests can be run on simulator.
* pr/902:
CLOUDSTACK-8924: Made changes based on the comments from @pvr9711
Signed-off-by: Remi Bergsma
> [Blocker] test duplicated in test_scale_vm.py
> -
>
> Key: CLOUDSTACK-8924
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8924
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
> Fix For: 4.6.0
>
>
> This is a blocker because BVTs for XS and Simulator are failing.
> Simulator zone - it is failing because
> This is a genuine failure - because the setup didn't have Dynamic Scaling
> enabled as part of global settings. Once it is enabled the tests ran fine.
> XS basic/Advzone - it is failing because
> the methods
> test_01_scale_vm(self):
> test_02_scale_vm_without_hypervisor_specifics(self):
> are essentially same with the exception of tags -
> first one - test_01_scale_vm - had a "required_hardware=true"
> second - test_02_scale_vm_without_hypervisor_specific had a
> "required_hardware=false"
> essentially we can get this test run on both Simulator and XenServer by
> modifying the "required_hardware=false".
> and test_02_scale_vm_without_hypervisor_specifc - can be deleted.
> The reason for failure on the XS is due to the following - "Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering"
> Following are the logs:
> Test scale virtual machine ... === TestName: test_01_scale_vm | Status :
> SUCCESS ===
> ok
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm) ... === TestName:
> test_02_scale_vm_without_hypervisor_specifics | Status : EXCEPTION ===
> ERROR
> ==
> ERROR: test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm)
> --
> Traceback (most recent call last):
> File "/root/cloudstack/test/integration/smoke/test_scale_vm.py", line 234,
> in test_02_scale_vm_without_hypervisor_specifics
> self.apiclient.scaleVirtualMachine(cmd)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 797, in scaleVirtualMachine
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line
> 379, in marvinRequest
> raise e
> Exception: Job failed: {jobprocstatus : 0, created :
> u'2015-09-30T01:16:45+', cmd :
> u'org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin', userid :
> u'd46c0476-670a-11e5-8245-96e5a2a4ae9a', jobstatus : 2, jobid :
> u'ad32dee5-da3c-42c3-bdc3-35928b47697f', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 431, errortext : u'Not upgrading vm
> VM[User|i-23-28-VM] since it already has the requested service offering
> (BigInstance)'}, accountid : u'd46bf47c-670a-11e5-8245-96e5a2a4ae9a'}
> >> begin captured stdout << -
> === TestName: test_02_scale_vm_without_hypervisor_specifics | Status :
> EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: STARTED :
> TC: test_02_scale_vm_without_hypervisor_specifics :::
> test_02_scale_vm_without_hypervisor_specifics
> (integration.smoke.test_scale_vm.TestScaleVm): DEBUG: Payload:
> {'isdynamicallyscalable': 'true', 'apiKey':
> u'FI3p7aHiRMfWK_oV_T9_i8uY-YegVuIR3mvV7pS3w7s_2-krRV-GMGXoBoVm0454fiZt6FgwOH86gEPenLox0w',
> 'response': 'json', 'command': 'updateVirtualMachine', 'signature':
> '4dANF6uDGtaOk6jIDb901ES+Oq8=', 'id': u'38c1ced0-693f-4e31-b976-9f4161ac57bb'}
>
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989443#comment-14989443 ] ASF GitHub Bot commented on CLOUDSTACK-8925: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1023#issuecomment-153701619 Jenkins error is not related. It says "no failures" but still shows a red button on Cloud Server. By the way, I pushed a python file.  > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989449#comment-14989449 ] ASF GitHub Bot commented on CLOUDSTACK-8925: Github user miguelaferreira commented on the pull request: https://github.com/apache/cloudstack/pull/1023#issuecomment-153701940 JVM died: https://builds.apache.org/job/cloudstack-pull-analysis/1150/org.apache.cloudstack$cloud-server/console > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9028) GloboDNS doen´t work with "Shared Networks"
Luciano Castro created CLOUDSTACK-9028: -- Summary: GloboDNS doen´t work with "Shared Networks" Key: CLOUDSTACK-9028 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9028 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.5.2 Environment: Cloudstack 4.5.2 with XenServer 6.5 Reporter: Luciano Castro Priority: Minor Hi! , * Goal: Try to use GloboDNS with "Shared network". * Problem: Got some errors when try to create the Network with Networking Service with DNSAPI. > URL Errors: -> https://www.dropbox.com/s/x0w6o1pczac0r45/adding_guest_network-error.PNG?dl=0 -> https://www.dropbox.com/s/p92p0ut5gr7t7p4/adding_guest_network.PNG?dl=0 How to reproduce? * After enable GloboDNS (in "Network Service Providers"), create "Network Offering" (DNS: GloboDNS), try to create a network with this service offering. *** At original spec(https://cwiki.apache.org/confluence/display/CLOUDSTACK/Bind+integration+by+Globo+DNSAPI), *** *** it´s not clear if it is supported with "Shared Networks", but when I try to add the Network, the option at the GUI is enable for me. *** But I receive this error: 2015-11-03 17:58:13,787 DEBUG [c.c.a.ApiServlet] (catalina-exec-3:ctx-fcc3f031) ===START=== 10.225.8.161 -- GET command=createNetwork&zoneId=3b00a6fa-379b-4ddb-a859-267ad433ed5e&networkOfferingId=a83a593b-44a0-4825-8fda-97c2073b4594&physicalnetworkid=77d61e10-100a-4bb9-ad34-1ec9d0d391ab&name=VLAN-DSV&displayText=VLAN-DSV&vlan=2900&acltype=domain&gateway=10.235.151.1&netmask=255.255.255.0&startip=10.235.151.8&endip=10.235.151.254&networkdomain=dsv-cloud.tpn.terra.com&response=json&_=1446573576495 2015-11-03 17:58:13,826 INFO [c.c.a.ApiServer] (catalina-exec-3:ctx-fcc3f031 ctx-ff209cc4) Cannot specify CIDR when using network offering with external devices! But I need specify a network, I´m using "Shared Networks". Dev team, can you check this? thanks Luciano Castro -- 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=14989468#comment-14989468 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-153704575 @koushik-das makes sense so we have a policy that for any sensitive field LogLevel(LogLevel.OFF) be used. We should add that as a comment to the enum to document it. > 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, > h
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989475#comment-14989475 ] ASF GitHub Bot commented on CLOUDSTACK-8925: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1023#issuecomment-153707458 A ticket is out for this at infra: INFRA-10703 > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989502#comment-14989502 ] ASF GitHub Bot commented on CLOUDSTACK-8925: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1023#issuecomment-153713989 @borisroman , could you please retest? It worked for me and for you, but not for @remibergsma due to a resolving thing on RVR test. I then ran it again and it did not work. Seems to be some intermittent thing. The new push add a egress rule to open UDP/53, which makes it work. It happens with RVR default egress DENY Cheers, Wilder > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989514#comment-14989514 ] ASF GitHub Bot commented on CLOUDSTACK-8925: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1023#issuecomment-153717404 Ping @borisroman @remibergsma @DaanHoogland @miguelaferreira @karuturi Test results: ``` 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 -- Ran 4 tests in 2005.385s OK /tmp//MarvinLogs/test_routers_network_ops_KVHJOX/results.txt (END) ``` > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9024) Restart network fails if redundant router is missing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989542#comment-14989542 ] dsclose commented on CLOUDSTACK-9024: - This appears to have been introduced as part of CLOUDSTACK-6433. Relevant commit: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=59a9db3 Commit title: Don't return success if only one RvR builds successfully. The point being that we need the network restart to succeed if only one virtual router is built. This conforms to Cloudstack documentation on how to deal with faulty routers: "If you are sure that a virtual router is down forever, or no longer functions as expected, destroy it. ... Recreate the missing router by using the restartNetwork API with cleanup=false parameter." http://cloudstack-administration.readthedocs.org/en/latest/troubleshooting.html#recovering-a-lost-virtual-router > Restart network fails if redundant router is missing > > > Key: CLOUDSTACK-9024 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9024 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Network Controller, Virtual Router >Affects Versions: 4.5.2 > Environment: Cloudstack installed on CentOS 6.5 >Reporter: dsclose > > Restart network action fails if a network is missing a redundant virtual > router. This occurs if triggered via the UI (Networks -> Select Network -> > Restart -> Clean-ip: False -> OK) or via the API. > Steps to reproduce: > > 1. Create a redundant router network offering. > 2. Create a network using the redundant router network offering. > 3. Destroy a redundant router from the network. Leave one functioning. > 4. Initiate the restart network action or restartNetwork API call with > clean-up set to False. > Expected Behaviour: > -- > Cloudstack should boot a new redundant virtual router to replace the missing > router. The Network Restart action should return successfully. > Actual Behaviour: > --- > Cloudstack boots a replacement redundant router but the API call returns > unsucessful. The Web UI reports that the router fails. > Timeline: > --- > 2015-11-03 17:12:08,256 Destroying router "r-985-VM". > 2015-11-03 17:12:24,511 Performing network restart. > 2015-11-03 17:14:02,851 Failed to restart network > Management Log Sample > - > 2015-11-03 17:12:14,943 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (Work-Job-Executor-12:ctx-a671c200 job-163/job-164) Remove job-164 from job > monitoring > 2015-11-03 17:12:15,739 INFO [o.a.c.s.v.VolumeServiceImpl] > (API-Job-Executor-12:ctx-33b24483 job-163 ctx-4d95a357) Volume 985 is not > referred anywhere, remove it from volumes table > 2015-11-03 17:12:15,850 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (API-Job-Executor-12:ctx-33b24483 job-163) Remove job-163 from job monitoring > 2015-11-03 17:12:18,698 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (API-Job-Executor-13:ctx-c29ad7f0 job-165) Add job-165 into job monitoring > 2015-11-03 17:12:18,985 INFO [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Use same MAC as > previous RvR, the MAC is 06:9c:86:00:00:0e > 2015-11-03 17:12:19,829 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (Work-Job-Executor-13:ctx-06672650 job-165/job-166) Add job-166 into job > monitoring > 2015-11-03 17:12:20,078 INFO [c.c.s.StorageManagerImpl] > (Work-Job-Executor-13:ctx-06672650 job-165/job-166 ctx-81c163bb) Storage pool > null (1) does not supply IOPS capacity, assuming enough capacity > 2015-11-03 17:12:40,248 INFO [c.c.v.VirtualMachineManagerImpl] > (DirectAgentCronJob-492:ctx-1fb6ecea) There is pending job or HA tasks > working on the VM. vm id: 992, postpone power-change report by resetting > power-change counters > 2015-11-03 17:13:40,384 INFO [c.c.v.VirtualMachineManagerImpl] > (DirectAgentCronJob-280:ctx-846ef4f0) There is pending job or HA tasks > working on the VM. vm id: 992, postpone power-change report by resetting > power-change counters > 2015-11-03 17:13:49,799 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] > (AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) Begin cleanup expired async-jobs > 2015-11-03 17:13:49,825 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] > (AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) End cleanup expired async-jobs > 2015-11-03 17:13:55,688 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (Work-Job-Executor-13:ctx-06672650 job-165/job-166) Remove job-166 from job > monitoring > 2015-11-03 17:13:55,730 WARN [o.a.c.e.o.NetworkOrchestrator] > (API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Failed to implement > network Ntwk[208|Guest|15] elements and resources as a
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989564#comment-14989564
]
ASF GitHub Bot commented on CLOUDSTACK-8925:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1023#issuecomment-153726658
LGTM, the test from this branch now succeed:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,required_hardware=true \
component/test_routers_network_ops.py
```
Result:
```
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
--
Ran 4 tests in 1812.275s
OK
```
> Default allow for Egress rules is not being configured properly in VR
> iptables rules
>
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0
>Reporter: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain
> which has a rule to accept NEW packets from the guest instances. Without that
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
> pkts bytes target prot opt in out source
> destination
>44 2832 NETWORK_STATS all -- * * 0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0
>state NEW
> 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0
>state RELATED,ESTABLISHED
>40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
> pkts bytes target prot opt in out source
> destination
> 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
> pkts bytes target prot opt in out source
> destination
> Chain FW_OUTBOUND (1 references)
> pkts bytes target prot opt in out source
> destination
> 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
>state RELATED,ESTABLISHED
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989567#comment-14989567 ] ASF subversion and git services commented on CLOUDSTACK-8925: - Commit ad4fbcd577598df542a15b5886d3ad16ea224b58 in cloudstack's branch refs/heads/master from [~wilder.rodrigues] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ad4fbcd ] CLOUDSTACK-8925 - Improve the default egress tests in order to cover newly entered rules > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989575#comment-14989575 ] ASF GitHub Bot commented on CLOUDSTACK-8925: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1023 > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989573#comment-14989573 ] ASF subversion and git services commented on CLOUDSTACK-8925: - Commit f948e96299f65f2c83ee902b0b46ea34a559064b in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f948e96 ] Merge pull request #1023 from ekholabs/fix/egress_state-CLOUDSTACK-8925 CLOUDSTACK-8925 - Default allow for Egress rules is not being configured properly in VR iptables rulesThis PR fixes the router default policy for egress. When the default is DENY, the router still allows outgoing connections. The test component/test_routers_network_ops.py was improved to cover that case as well. The results were: 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 -- Ran 4 tests in 3636.656s OK /tmp//MarvinLogs/test_routers_network_ops_QDL429/results.txt (END) * pr/1023: CLOUDSTACK-8925 - Implement the default egress DENY/ALLOW properly CLOUDSTACK-8925 - Improve the default egress tests in order to cover newly entered rules CLOUDSTACK-8925 - Add egress dataset to test_data.py CLOUDSTACK-8925 - Drop the traffic when default egress is set to false Signed-off-by: Remi Bergsma > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989568#comment-14989568 ] ASF subversion and git services commented on CLOUDSTACK-8925: - Commit 79dabfdae440baafede15569845b6a280b9b46eb in cloudstack's branch refs/heads/master from [~wilder.rodrigues] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=79dabfd ] CLOUDSTACK-8925 - Implement the default egress DENY/ALLOW properly - Make tests work with right IP and rules - Add egress rule for port 53 protocol UDP when testing default egress DENY on RVR > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989570#comment-14989570 ] ASF subversion and git services commented on CLOUDSTACK-8925: - Commit f948e96299f65f2c83ee902b0b46ea34a559064b in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f948e96 ] Merge pull request #1023 from ekholabs/fix/egress_state-CLOUDSTACK-8925 CLOUDSTACK-8925 - Default allow for Egress rules is not being configured properly in VR iptables rulesThis PR fixes the router default policy for egress. When the default is DENY, the router still allows outgoing connections. The test component/test_routers_network_ops.py was improved to cover that case as well. The results were: 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 -- Ran 4 tests in 3636.656s OK /tmp//MarvinLogs/test_routers_network_ops_QDL429/results.txt (END) * pr/1023: CLOUDSTACK-8925 - Implement the default egress DENY/ALLOW properly CLOUDSTACK-8925 - Improve the default egress tests in order to cover newly entered rules CLOUDSTACK-8925 - Add egress dataset to test_data.py CLOUDSTACK-8925 - Drop the traffic when default egress is set to false Signed-off-by: Remi Bergsma > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989566#comment-14989566 ] ASF subversion and git services commented on CLOUDSTACK-8925: - Commit 334daef78f47b59de267ab7025302d32e0c6e87b in cloudstack's branch refs/heads/master from [~wilder.rodrigues] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=334daef ] CLOUDSTACK-8925 - Add egress dataset to test_data.py > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989574#comment-14989574 ] ASF subversion and git services commented on CLOUDSTACK-8925: - Commit f948e96299f65f2c83ee902b0b46ea34a559064b in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f948e96 ] Merge pull request #1023 from ekholabs/fix/egress_state-CLOUDSTACK-8925 CLOUDSTACK-8925 - Default allow for Egress rules is not being configured properly in VR iptables rulesThis PR fixes the router default policy for egress. When the default is DENY, the router still allows outgoing connections. The test component/test_routers_network_ops.py was improved to cover that case as well. The results were: 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 -- Ran 4 tests in 3636.656s OK /tmp//MarvinLogs/test_routers_network_ops_QDL429/results.txt (END) * pr/1023: CLOUDSTACK-8925 - Implement the default egress DENY/ALLOW properly CLOUDSTACK-8925 - Improve the default egress tests in order to cover newly entered rules CLOUDSTACK-8925 - Add egress dataset to test_data.py CLOUDSTACK-8925 - Drop the traffic when default egress is set to false Signed-off-by: Remi Bergsma > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989565#comment-14989565 ] ASF subversion and git services commented on CLOUDSTACK-8925: - Commit caa0b4071c024b6672519ab811be733344a05086 in cloudstack's branch refs/heads/master from [~wilder.rodrigues] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=caa0b40 ] CLOUDSTACK-8925 - Drop the traffic when default egress is set to false - The DROP rule should be appended and the other rules inserted. > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989569#comment-14989569 ] ASF subversion and git services commented on CLOUDSTACK-8925: - Commit f948e96299f65f2c83ee902b0b46ea34a559064b in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f948e96 ] Merge pull request #1023 from ekholabs/fix/egress_state-CLOUDSTACK-8925 CLOUDSTACK-8925 - Default allow for Egress rules is not being configured properly in VR iptables rulesThis PR fixes the router default policy for egress. When the default is DENY, the router still allows outgoing connections. The test component/test_routers_network_ops.py was improved to cover that case as well. The results were: 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 -- Ran 4 tests in 3636.656s OK /tmp//MarvinLogs/test_routers_network_ops_QDL429/results.txt (END) * pr/1023: CLOUDSTACK-8925 - Implement the default egress DENY/ALLOW properly CLOUDSTACK-8925 - Improve the default egress tests in order to cover newly entered rules CLOUDSTACK-8925 - Add egress dataset to test_data.py CLOUDSTACK-8925 - Drop the traffic when default egress is set to false Signed-off-by: Remi Bergsma > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989572#comment-14989572 ] ASF subversion and git services commented on CLOUDSTACK-8925: - Commit f948e96299f65f2c83ee902b0b46ea34a559064b in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f948e96 ] Merge pull request #1023 from ekholabs/fix/egress_state-CLOUDSTACK-8925 CLOUDSTACK-8925 - Default allow for Egress rules is not being configured properly in VR iptables rulesThis PR fixes the router default policy for egress. When the default is DENY, the router still allows outgoing connections. The test component/test_routers_network_ops.py was improved to cover that case as well. The results were: 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 -- Ran 4 tests in 3636.656s OK /tmp//MarvinLogs/test_routers_network_ops_QDL429/results.txt (END) * pr/1023: CLOUDSTACK-8925 - Implement the default egress DENY/ALLOW properly CLOUDSTACK-8925 - Improve the default egress tests in order to cover newly entered rules CLOUDSTACK-8925 - Add egress dataset to test_data.py CLOUDSTACK-8925 - Drop the traffic when default egress is set to false Signed-off-by: Remi Bergsma > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989571#comment-14989571 ] ASF subversion and git services commented on CLOUDSTACK-8925: - Commit f948e96299f65f2c83ee902b0b46ea34a559064b in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f948e96 ] Merge pull request #1023 from ekholabs/fix/egress_state-CLOUDSTACK-8925 CLOUDSTACK-8925 - Default allow for Egress rules is not being configured properly in VR iptables rulesThis PR fixes the router default policy for egress. When the default is DENY, the router still allows outgoing connections. The test component/test_routers_network_ops.py was improved to cover that case as well. The results were: 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 -- Ran 4 tests in 3636.656s OK /tmp//MarvinLogs/test_routers_network_ops_QDL429/results.txt (END) * pr/1023: CLOUDSTACK-8925 - Implement the default egress DENY/ALLOW properly CLOUDSTACK-8925 - Improve the default egress tests in order to cover newly entered rules CLOUDSTACK-8925 - Add egress dataset to test_data.py CLOUDSTACK-8925 - Drop the traffic when default egress is set to false Signed-off-by: Remi Bergsma > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wilder Rodrigues resolved CLOUDSTACK-8925. -- Resolution: Fixed merged > Default allow for Egress rules is not being configured properly in VR > iptables rules > > > Key: CLOUDSTACK-8925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Wilder Rodrigues >Priority: Blocker > Fix For: 4.6.0 > > > When we create a network with Egress rules set to default allow, the rules > created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain > which has a rule to accept NEW packets from the guest instances. Without that > rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop > of packets. > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination >44 2832 NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state NEW > 4 336 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >40 2496 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 > 0.0.0.0/0 > Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes) > pkts bytes target prot opt in out source > destination > 2498 369K NETWORK_STATS all -- * * 0.0.0.0/0 > 0.0.0.0/0 > Chain FIREWALL_EGRESS_RULES (0 references) > pkts bytes target prot opt in out source > destination > Chain FW_OUTBOUND (1 references) > pkts bytes target prot opt in out source > destination > 3 252 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6433) Make sure redundant router would create a pair of routers when implementation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989602#comment-14989602 ] dsclose commented on CLOUDSTACK-6433: - This may have introduced a bug regarding restarting a network when at least one redundant router has been destroyed: CLOUDSTACK-9024 > Make sure redundant router would create a pair of routers when implementation > - > > Key: CLOUDSTACK-6433 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6433 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0, 4.5.0, 4.3.1 >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.4.0, 4.5.0, 4.3.1 > > > When implementing RvR, we only make sure there is at least one VR created for > the network. But for RvR, we should make sure both routers are created > successful, otherwise implementation should fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9024) Restart network fails if redundant router is missing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989620#comment-14989620 ] ASF GitHub Bot commented on CLOUDSTACK-9024: Github user dsclose commented on the pull request: https://github.com/apache/cloudstack/commit/59a9db39b1d17056753385c0e091bfe26d2df522#commitcomment-14184110 Issue CLOUDSTACK-9024 refers to this commit. https://issues.apache.org/jira/browse/CLOUDSTACK-9024 > Restart network fails if redundant router is missing > > > Key: CLOUDSTACK-9024 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9024 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Network Controller, Virtual Router >Affects Versions: 4.5.2 > Environment: Cloudstack installed on CentOS 6.5 >Reporter: dsclose > > Restart network action fails if a network is missing a redundant virtual > router. This occurs if triggered via the UI (Networks -> Select Network -> > Restart -> Clean-ip: False -> OK) or via the API. > Steps to reproduce: > > 1. Create a redundant router network offering. > 2. Create a network using the redundant router network offering. > 3. Destroy a redundant router from the network. Leave one functioning. > 4. Initiate the restart network action or restartNetwork API call with > clean-up set to False. > Expected Behaviour: > -- > Cloudstack should boot a new redundant virtual router to replace the missing > router. The Network Restart action should return successfully. > Actual Behaviour: > --- > Cloudstack boots a replacement redundant router but the API call returns > unsucessful. The Web UI reports that the router fails. > Timeline: > --- > 2015-11-03 17:12:08,256 Destroying router "r-985-VM". > 2015-11-03 17:12:24,511 Performing network restart. > 2015-11-03 17:14:02,851 Failed to restart network > Management Log Sample > - > 2015-11-03 17:12:14,943 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (Work-Job-Executor-12:ctx-a671c200 job-163/job-164) Remove job-164 from job > monitoring > 2015-11-03 17:12:15,739 INFO [o.a.c.s.v.VolumeServiceImpl] > (API-Job-Executor-12:ctx-33b24483 job-163 ctx-4d95a357) Volume 985 is not > referred anywhere, remove it from volumes table > 2015-11-03 17:12:15,850 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (API-Job-Executor-12:ctx-33b24483 job-163) Remove job-163 from job monitoring > 2015-11-03 17:12:18,698 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (API-Job-Executor-13:ctx-c29ad7f0 job-165) Add job-165 into job monitoring > 2015-11-03 17:12:18,985 INFO [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Use same MAC as > previous RvR, the MAC is 06:9c:86:00:00:0e > 2015-11-03 17:12:19,829 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (Work-Job-Executor-13:ctx-06672650 job-165/job-166) Add job-166 into job > monitoring > 2015-11-03 17:12:20,078 INFO [c.c.s.StorageManagerImpl] > (Work-Job-Executor-13:ctx-06672650 job-165/job-166 ctx-81c163bb) Storage pool > null (1) does not supply IOPS capacity, assuming enough capacity > 2015-11-03 17:12:40,248 INFO [c.c.v.VirtualMachineManagerImpl] > (DirectAgentCronJob-492:ctx-1fb6ecea) There is pending job or HA tasks > working on the VM. vm id: 992, postpone power-change report by resetting > power-change counters > 2015-11-03 17:13:40,384 INFO [c.c.v.VirtualMachineManagerImpl] > (DirectAgentCronJob-280:ctx-846ef4f0) There is pending job or HA tasks > working on the VM. vm id: 992, postpone power-change report by resetting > power-change counters > 2015-11-03 17:13:49,799 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] > (AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) Begin cleanup expired async-jobs > 2015-11-03 17:13:49,825 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] > (AsyncJobMgr-Heartbeat-1:ctx-10ff7f5f) End cleanup expired async-jobs > 2015-11-03 17:13:55,688 INFO [o.a.c.f.j.i.AsyncJobMonitor] > (Work-Job-Executor-13:ctx-06672650 job-165/job-166) Remove job-166 from job > monitoring > 2015-11-03 17:13:55,730 WARN [o.a.c.e.o.NetworkOrchestrator] > (API-Job-Executor-13:ctx-c29ad7f0 job-165 ctx-7945f6f9) Failed to implement > network Ntwk[208|Guest|15] elements and resources as a part of network > restart due to > com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is > unreachable: Can't find all necessary running routers! > at > com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:202) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1103) >
[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=14989636#comment-14989636
]
ASF GitHub Bot commented on CLOUDSTACK-8485:
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/1021#issuecomment-153749695
```
2015-11-04 14:23:51,076 DEBUG [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-34:ctx-0d2ee513 job-104/job-105 ctx-0d5c6252) Done executing
VM work job: com.cloud.vm.VmWorkStart{"dcId
":1,"podId":1,"clusterId":1,"hostId":2,"rawParams":{"VmPassword":""},"userId":2,"accountId":2,"vmId":13,"handlerName":"VirtualMachineManagerImpl"}
```
And some other examples in there. I am looking further. @koushik-das this
is going to take a lot of work to get right, right? Like this it is not done I
think.
> 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,
[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=14989662#comment-14989662 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1021#issuecomment-153755733 @koushik-das On second thought LogLevel can not be used I think: It is used for json serialization and one might have to serialize a password to be send to an agent while it may not be logged at the same time. We do need a separate annotation. this is not going to fly and hide sensitive data at the same time. > 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.s
[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=14989672#comment-14989672
]
ASF GitHub Bot commented on CLOUDSTACK-8485:
Github user DaanHoogland commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1021#discussion_r43891649
--- Diff:
api/src/org/apache/cloudstack/api/response/SSHKeyPairResponse.java ---
@@ -40,6 +42,7 @@
@SerializedName("fingerprint")
@Param(description = "Fingerprint of the public key")
+@LogLevel(Log4jLevel.Off)
--- End diff --
why is fingerprint sensitive?
> listAPIs are taking too long to return results
> --
>
> Key: CLOUDSTACK-8485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.5.1, 4.6.0
>Reporter: Sowmya Krishnan
>Assignee: Koushik Das
> Fix For: 4.6.0
>
>
> listAPIs are taking significantly longer than before (4.2.x)
> I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K
> Routers. Here are few results:
> listVirtualMachines is taking > 25 sec to return with pagesize set to 50.
> This is in comparison to 2 sec in earlier cases such as 4.2.
> listVolumes with pagesize = 1000 took more than 10 mins and finally times out.
> Further observations show that there are also lot of slow queries being
> logged in catalina.out and in MySQL slow query logs. I am not sure if this
> could be the reason for DB performance getting impacted in turn causing an
> impact on listAPIs too.
> Here's a sample of slow queries from catalina.out:
> Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 3305 ms, connection-id: 637759, statement-id: 3218312,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305
> ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name,
> user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE
> user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler
> Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 3305 ms, connection-id: 637843, statement-id: 3218311,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type,
> host.private_ip_address, host.private_mac_address, host.private_netmask,
> host.public_netmask, host.public_ip_address, host.public_mac_address,
> host.storage_ip_address, host.cluster_id, host.storage_netmask,
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2,
> host.storage_mac_address_2, host.hypervisor_type, host.proxy_port,
> host.resource, host.fs_type, host.available, host.setup, host.resource_state,
> host.hypervisor_version, host.update_count, host.uuid, host.data_center_id,
> host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram,
> host.parent, host.guid, host.capabilities, host.total_size, host.last_ping,
> host.mgmt_server_id, host.dom0_memory, host.version, host.created,
> host.removed FROM host WHERE host.id = 345 AND host.removed IS NULL
> Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 6458 ms, connection-id: 637623, statement-id: 3218243,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458
> ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref INNER
> JOIN host ON storage_pool_host_ref.host_id=host.id WHERE
> storage_pool_host_ref.pool_id = 197 AND (host.status = 'Up' AND
> host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler
> Event: [SLOW QUERY] at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> duration: 2402 ms, connection-id: 637754, statement-id: 3218371,
> resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402
> ms):SELECT host.id, host.disconnected, host.name, host.status, host.type,
> host.private_ip_address, host.private_mac_address, host.private_netmask,
> host.public_netmask, host.public_ip_address, host.public_mac_address,
> host.storage_ip_address, host.cluster_id, host.storage_netmask,
> host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2,
> host.
[jira] [Commented] (CLOUDSTACK-8485) listAPIs are taking too long to return results
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989675#comment-14989675 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user DaanHoogland commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1021#discussion_r43892103 --- Diff: api/src/org/apache/cloudstack/api/response/SslCertResponse.java --- @@ -38,6 +40,7 @@ @SerializedName(ApiConstants.CERTIFICATE) @Param(description = "certificate") +@LogLevel(Log4jLevel.Off) --- End diff -- certificates are not sensitive data. They are meant to be public. > 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.s
[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=14989770#comment-14989770 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user DaanHoogland commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1021#discussion_r43897730 --- Diff: api/src/org/apache/cloudstack/api/response/SslCertResponse.java --- @@ -62,10 +65,12 @@ @SerializedName(ApiConstants.CERTIFICATE_CHAIN) @Param(description = "certificate chain") +@LogLevel(Log4jLevel.Off) --- End diff -- cert chain is not sensitive data. > 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,
[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=14989777#comment-14989777 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user DaanHoogland commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1021#discussion_r43898186 --- Diff: api/src/org/apache/cloudstack/api/response/UserVmResponse.java --- @@ -256,6 +259,7 @@ @SerializedName(ApiConstants.SSH_KEYPAIR) @Param(description = "ssh key-pair") +@LogLevel(Log4jLevel.Off) --- End diff -- why is the keypair name sensitive? > listAPIs are taking too long to return results > -- > > Key: CLOUDSTACK-8485 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8485 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.1, 4.6.0 >Reporter: Sowmya Krishnan >Assignee: Koushik Das > Fix For: 4.6.0 > > > listAPIs are taking significantly longer than before (4.2.x) > I tried out few listAPI calls using a simulator set up with ~ 10K VMs and 8K > Routers. Here are few results: > listVirtualMachines is taking > 25 sec to return with pagesize set to 50. > This is in comparison to 2 sec in earlier cases such as 4.2. > listVolumes with pagesize = 1000 took more than 10 mins and finally times out. > Further observations show that there are also lot of slow queries being > logged in catalina.out and in MySQL slow query logs. I am not sure if this > could be the reason for DB performance getting impacted in turn causing an > impact on listAPIs too. > Here's a sample of slow queries from catalina.out: > Mon May 11 07:31:15 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637759, statement-id: 3218312, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT user_vm_details.id, user_vm_details.vm_id, user_vm_details.name, > user_vm_details.value, user_vm_details.display FROM user_vm_details WHERE > user_vm_details.vm_id = 9117Mon May 11 07:31:15 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 3305 ms, connection-id: 637843, statement-id: 3218311, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 3,305 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.storage_mac_address_2, host.hypervisor_type, host.proxy_port, > host.resource, host.fs_type, host.available, host.setup, host.resource_state, > host.hypervisor_version, host.update_count, host.uuid, host.data_center_id, > host.pod_id, host.cpu_sockets, host.cpus, host.url, host.speed, host.ram, > host.parent, host.guid, host.capabilities, host.total_size, host.last_ping, > host.mgmt_server_id, host.dom0_memory, host.version, host.created, > host.removed FROM host WHERE host.id = 345 AND host.removed IS NULL > Mon May 11 07:31:17 UTC 2015 INFO: Profiler Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 6458 ms, connection-id: 637623, statement-id: 3218243, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 6,458 > ms):SELECT storage_pool_host_ref.host_id FROM storage_pool_host_ref INNER > JOIN host ON storage_pool_host_ref.host_id=host.id WHERE > storage_pool_host_ref.pool_id = 197 AND (host.status = 'Up' AND > host.resource_state = 'Enabled' )Mon May 11 07:31:17 UTC 2015 INFO: Profiler > Event: [SLOW QUERY] at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > duration: 2402 ms, connection-id: 637754, statement-id: 3218371, > resultset-id: 0, message: Slow query (exceeded 2,000 ms, duration: 2,402 > ms):SELECT host.id, host.disconnected, host.name, host.status, host.type, > host.private_ip_address, host.private_mac_address, host.private_netmask, > host.public_netmask, host.public_ip_address, host.public_mac_address, > host.storage_ip_address, host.cluster_id, host.storage_netmask, > host.storage_mac_address, host.storage_ip_address_2, host.storage_netmask_2, > host.stor
[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=14989787#comment-14989787 ] ASF GitHub Bot commented on CLOUDSTACK-8485: Github user DaanHoogland commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1021#discussion_r43898594 --- Diff: server/src/com/cloud/api/ApiResponseGsonHelper.java --- @@ -27,30 +29,40 @@ import com.google.gson.GsonBuilder; /** - * The ApiResonseGsonHelper is different from ApiGsonHelper - it registeres one more adapter for String type required for api response encoding + * The ApiResonseGsonHelper is different from ApiGsonHelper - it registers one more adapter for String type required for api response encoding --- End diff -- We should upgrade gson before further expanding on this feature of it. Exlusion strategies have somewhat changed in version 2 in the sense that exclusion is cahced inside gson and a change in loglevel is not endorsed. > 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:
[jira] [Commented] (CLOUDSTACK-8787) Network Update from Standalone VR offering to RVR offering is failing with Runtime Exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989792#comment-14989792 ] dsclose commented on CLOUDSTACK-8787: - The code that throws this exception: com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is unreachable: Can't find all necessary running routers! is relevant to issue Cloudstack-9024. Has Cloudstack-9024 been resolved in Cloudstack-8844 as well? > Network Update from Standalone VR offering to RVR offering is failing with > Runtime Exception > > > Key: CLOUDSTACK-8787 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8787 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Deepthi Machiraju > Fix For: 4.6.0 > > Attachments: management-server.zip, mysqlcloud.dmp > > > - Deploy a network with Standalone offering ID . > - Navigate to Network and update the offering from Standalone -> RVR. > Expected Result : > Network Update should be sucessful > Observation: > Network update is failing with the following below exception : " failed to > update network 637b4d16-a2ef-464c-a805-2375774a5730due to Failed to implement > network (with specified id) elements and resources as a part of network > update " > 015-08-31 10:59:13,044 DEBUG [c.c.v.VmWorkJobDispatcher] > (Work-Job-Executor-87:ctx-d2e23154 job-141/job-144) Done with run of VM work > job: com.cloud.vm.VmWorkStart for VM 33, job origin: 141 > 2015-08-31 10:59:13,044 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] > (Work-Job-Executor-87:ctx-d2e23154 job-141/job-144) Done executing > com.cloud.vm.VmWorkStart for job-144 > 2015-08-31 10:59:13,049 WARN [c.c.n.NetworkServiceImpl] > (API-Job-Executor-47:ctx-14794ea0 job-141 ctx-70358d9a) Failed to implement > network Ntwk[206|Guest|18] elements and resources as a part of network update > due to > com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is > unreachable: Can't find all necessary running routers! > at > com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:227) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1113) > at > com.cloud.network.NetworkServiceImpl.updateGuestNetwork(NetworkServiceImpl.java:2354) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy161.updateGuestNetwork(Unknown Source) > at > org.apache.cloudstack.api.command.admin.network.UpdateNetworkCmdByAdmin.execute(UpdateNetworkCmdByAdmin.java:51) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(Defa
[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=14989795#comment-14989795
]
ASF GitHub Bot commented on CLOUDSTACK-8485:
Github user DaanHoogland commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1021#discussion_r43899212
--- Diff: server/src/com/cloud/api/ApiResponseGsonHelper.java ---
@@ -71,4 +83,19 @@ public boolean shouldSkipField(FieldAttributes f) {
return false;
}
}
+
+private static class LogExclusionStrategy extends
ApiResponseExclusionStrategy implements ExclusionStrategy {
--- End diff --
LoggingExclusionStrategy allready exists. It shouldn't be needed to
implement again.
> 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_addr
