[jira] [Commented] (CLOUDSTACK-9498) VR CsFile search utility methods fail when search string has char *, + etc

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15525177#comment-15525177
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9498:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1680
  
@jburwell changed the existing marvin test to use password as 
"p@a#s=s.w_o-r+d", which will cover the all chars permitted for VPN user 
password


> VR CsFile search utility methods fail when search string has char *, + etc
> --
>
> Key: CLOUDSTACK-9498
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9498
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.8.1, 4.9.0
>Reporter: Murali Reddy
>Assignee: Murali Reddy
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> VR CsFile search utility methods fail when search string has char *, + etc.
> These utility methods in CsFile [1] uses python regular expression module to 
> search a string in a file. However, if caller passes a search string, that 
> has chars *, +, . etc that are also happen to be express wild card / match 
> expression in regular expression results in exceptions from python 're' 
> module.
> For instance searching for VPN user [2] passes "username * password *" as 
> search string, if password has chars the interfer with regular expression 
> metacharecters then search will result in exception.
> 2016-09-12 13:55:48,976 configure.py add_l2tp_ipsec_user:569 Adding vpn user 
> murali * abcd++efgh## *
> 2016-09-12 13:55:48,976 CsFile.py load:39 Reading file /etc/ppp/chap-secrets
> 2016-09-12 13:55:48,976 CsFile.py searchString:140 Searching for murali * 
> abcd++efgh## * string
> 2016-09-12 13:55:48,976 configure.py main:1020 Exception while configuring 
> router
> Traceback (most recent call last):
> File "/opt/cloud/bin/configure.py", line 965, in main
> vpnuser.process()
> File "/opt/cloud/bin/configure.py", line 559, in process
> self.add_l2tp_ipsec_user(user, userconfig)
> File "/opt/cloud/bin/configure.py", line 572, in add_l2tp_ipsec_user
> userfound = file.searchString(userSearchEntry, '#')
> File "/opt/cloud/bin/cs/CsFile.py", line 146, in searchString
> if re.search(search, line):
> File "/usr/lib/python2.7/re.py", line 142, in search
> return _compile(pattern, flags).search(string)
> File "/usr/lib/python2.7/re.py", line 242, in _compile
> raise error, v # invalid expression
> 1 
> https://github.com/apache/cloudstack/blob/master/systemvm/patches/debian/config/opt/cloud/bin/cs/CsFile.py
> 2 
> https://github.com/apache/cloudstack/blob/master/systemvm/patches/debian/config/opt/cloud/bin/configure.py#L572



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15524937#comment-15524937
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
@murali-reddy there is a potential to move some of the code into net 
utility classes, think about it.


> Virtual Routers don't handle Multiple Public Interfaces
> ---
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
>Reporter: dsclose
>  Labels: firewall, nat, router
>
> There are a series of issues with the way Virtual Routers manage multiple 
> public interfaces. These are more pronounced on redundant virtual router 
> setups. I have not attempted to examine these issues in a VPC context. 
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on 
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue 
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will 
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT 
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate 
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and 
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how 
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The 
> master.py script is responsible for setting public interfaces to UP during a 
> keepalived transition. Currently the check_is_up method of the CsIP class 
> brings all interfaces UP on both RvR. A proposed fix for this has been 
> discussed on the mailing list. That fix will leave public interfaces DOWN on 
> RvR allowing the keepalived transition to control the state of public 
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix 
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. 
> Assuming public interfaces should be default be DOWN on an RvR we need to 
> accommodate the fact that, as interfaces are created, no keepalived 
> transition occurs. This means that assigning an IP from a new public subnet 
> will have no effect (as the interface will be down) until the network is 
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two 
> iptables rules in the FORWARD chain of the filter table created for eth2 that 
> allow forwarding between eth2 and eth0. Equivalent rules are not created for 
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, 
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New 
> connections from guests that are destined for public networks are processed 
> like so:
> 1. Traffic is matched against the following rule in the mangle table that 
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
> 2. There are no "ip rule" statements that match a connection marked 0x0, so 
> the kernel routes the connection via the default gateway. That gateway is on 
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, the following rule is matched from the nat table, where the IP 
> address is the source-NAT IP:
> *nat
> -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15524933#comment-15524933
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user abhinandanprateek commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1659#discussion_r80615061
  
--- Diff: test/integration/component/test_multiple_public_interfaces.py ---
@@ -0,0 +1,1365 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+""" BVT tests for network services on public IP's from different public IP
+  range than that of associated source NAT IP of the network. Each IP 
associated
+  with network from a different public IP range results in a new public
+  interface on VR (eth3, eth4 etc) and iptable
+"""
+# Import Local Modules
+from marvin.codes import (FAILED, STATIC_NAT_RULE, LB_RULE,
+  NAT_RULE, PASS)
+from marvin.cloudstackTestCase import cloudstackTestCase
+from marvin.cloudstackException import CloudstackAPIException
+from marvin.cloudstackAPI import rebootRouter
+from marvin.sshClient import SshClient
+from marvin.lib.utils import cleanup_resources, get_process_status
+from marvin.lib.base import (Account,
+ VirtualMachine,
+ ServiceOffering,
+ NATRule,
+ PublicIPAddress,
+ StaticNATRule,
+ FireWallRule,
+ Network,
+ NetworkOffering,
+ LoadBalancerRule,
+ PublicIpRange,
+ Router,
+ VpcOffering,
+ VPC,
+ NetworkACL)
+from marvin.lib.common import (get_domain,
+   get_zone,
+   get_template,
+   list_hosts,
+   list_publicIP,
+   list_nat_rules,
+   list_routers,
+   list_virtual_machines,
+   list_lb_rules,
+   list_configurations,
+   verifyGuestTrafficPortGroups)
+from nose.plugins.attrib import attr
+from ddt import ddt, data
+# Import System modules
+import socket
+import time
+import logging
+
+_multiprocess_shared_ = True
+
+logger = logging.getLogger('TestNetworkOps')
+stream_handler = logging.StreamHandler()
+logger.setLevel(logging.DEBUG)
+logger.addHandler(stream_handler)
+
+class TestPortForwarding(cloudstackTestCase):
+
+@classmethod
+def setUpClass(cls):
+
+testClient = super(TestPortForwarding, cls).getClsTestClient()
+cls.apiclient = testClient.getApiClient()
+cls.services = testClient.getParsedTestDataConfig()
+cls.hypervisor = testClient.getHypervisorInfo()
+# Get Zone, Domain and templates
+cls.domain = get_domain(cls.apiclient)
+cls.zone = get_zone(cls.apiclient, testClient.getZoneForTests())
+cls.services["virtual_machine"]["zoneid"] = cls.zone.id
+cls.services["zoneid"] = cls.zone.id
+template = get_template(
+cls.apiclient,
+cls.zone.id,
+cls.services["ostype"]
+)
+if template == FAILED:
+assert False, "get_template() failed to return template with 
description %s" % cls.services[
+"ostype"]
+
+# Create an account, network, VM and IP addresses
+cls.account = Account.create(
+cls.apiclient,
+cls.services["account"],
+admin=True,
+  

[jira] [Commented] (CLOUDSTACK-9505) Fix test_deploy_vgpu_enabled tests cleanup

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15523483#comment-15523483
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9505:


GitHub user nvazquez opened a pull request:

https://github.com/apache/cloudstack/pull/1693

CLOUDSTACK-9505: Fix test_deploy_vgpu_enabled tests cleanup

JIRA TICKET: https://issues.apache.org/jira/browse/CLOUDSTACK-9505

## Description
Cleanup resources after running `test_deploy_vgpu_enabled.py`. Although 
test passes, resources are left and need to be cleaned up

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nvazquez/cloudstack fix3dputest

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1693.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 #1693


commit 8f35e8d4125ab1968dd258c40674c0709c06
Author: nvazquez 
Date:   2016-09-26T16:08:31Z

CLOUDSTACK-9505: Fix test_deploy_vgpu_enabled tests cleanup




> Fix test_deploy_vgpu_enabled tests cleanup
> --
>
> Key: CLOUDSTACK-9505
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9505
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> Cleanup resources after running {{test_deploy_vgpu_enabled.py}}. Although 
> test passes, resources are left and need to be cleaned up



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15523213#comment-15523213
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9489:


Github user dagsonstebo commented on the issue:

https://github.com/apache/cloudstack/pull/1684
  
@pdion891 - client system so limited access, not got cloudmonkey access but 
here's what's in the DB:

mysql> select name from configuration;
| name|
| account.cleanup.interval|
| affinity.processors.exclude |
| affinity.processors.order   |
| agent.lb.enabled|
| agent.load.threshold|
| alert.email.addresses   |
| alert.email.sender  |
| alert.purge.delay   |
| alert.purge.interval|
| alert.smtp.connectiontimeout|
| alert.smtp.host |
| alert.smtp.password |
| alert.smtp.port |
| alert.smtp.timeout  |
| alert.smtp.useAuth  |
| alert.smtp.username |
| alert.wait  |
| allow.public.user.templates |
| allow.subdomain.network.access  |
| allow.user.create.projects  |
| allow.user.expunge.recover.vm   |
| allow.user.view.destroyed.vm|
| api.checkers.exclude|
| api.throttling.cachesize|
| api.throttling.enabled  |
| api.throttling.interval |
| api.throttling.max  |
| apply.allocation.algorithm.to.pods  |
| backup.snapshot.wait|
| baremetal.ipmi.fail.retry   |
| baremetal.ipmi.lan.interface|
| blacklisted.routes  |
| capacity.check.period   |
| capacity.skipcounting.hours |
| check.pod.cidrs |
| check.txn.before.sending.agent.commands |
| cloud.dns.name  |
| cloud.identifier|
| cloudbyte.management.apikey |
| cloudbyte.management.ip |
| cluster.cpu.allocated.capacity.disablethreshold |
| cluster.cpu.allocated.capacity.notificationthreshold|
| cluster.heartbeat.interval  |
| cluster.heartbeat.threshold |
| cluster.localStorage.capacity.notificationthreshold |
| cluster.memory.allocated.capacity.disablethreshold  |
| cluster.memory.allocated.capacity.notificationthreshold |
| cluster.message.timeout.seconds |
| cluster.storage.allocated.capacity.notificationthreshold|
| cluster.storage.capacity.notificationthreshold  |
| cluster.storage.operations.exclude  |
| concurrent.snapshots.threshold.perhost  |
| console.proxy.allocator.exclude |
| consoleproxy.capacity.standby   |
| consoleproxy.capacityscan.interval  |
| consoleproxy.cmd.port   |
| consoleproxy.disable.rpfilter   |
| consoleproxy.launch.max |
| consoleproxy.loadscan.interval  |
| consoleproxy.management.state   |
| consoleproxy.management.state.last  |
| consoleproxy.restart|
| consoleproxy.service.offering   |
| consoleproxy.session.max|
| consoleproxy.session.timeout|

[jira] [Commented] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15523198#comment-15523198
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9489:


Github user pdion891 commented on the issue:

https://github.com/apache/cloudstack/pull/1684
  
@dagsonstebo for your scenario 2 can you get the count of global settings ? 

via cloudmonkey as admin:
```
list configurations
```
You should have a count of about 468.

Also this current PR did apply some changes from the Config.java that were 
not applied in your upgrades. I have test upgrade path without this fix and I 
had no issues, but we end up with missing configurations entrees.


> When upgrading, Config.java new configuration are not updated.
> --
>
> Key: CLOUDSTACK-9489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Blocker
>
> When Upgrading CloudStack, new configurations (Global Settings) defined in  
> {{server/src/com/cloud/configuration/Config.java}} are not populated.
> This file changed in 4.5 and 4.6 and those configurations are not applied 
> when upgrading to post 4.6.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15523174#comment-15523174
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9489:


Github user dagsonstebo commented on the issue:

https://github.com/apache/cloudstack/pull/1684
  
@pdion891 in my list above:

1) Was an upgrade CCP4.5.1 to ACS4.5.2 - and this was where we potentially 
saw a bug, but never proven.
2) Was an upgrade CCP3.0.7 to ACS4.9.0 - no issues found.


> When upgrading, Config.java new configuration are not updated.
> --
>
> Key: CLOUDSTACK-9489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Blocker
>
> When Upgrading CloudStack, new configurations (Global Settings) defined in  
> {{server/src/com/cloud/configuration/Config.java}} are not populated.
> This file changed in 4.5 and 4.6 and those configurations are not applied 
> when upgrading to post 4.6.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9491) Vmware resource: incorrect parsing of device list to find ethener index of plugged nic

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15523171#comment-15523171
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9491:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1681
  
@sateesh-chodapuneedi  added optimization for now, but its better we 
eliminate the whole logic of finding device index from the VR.


> Vmware resource: incorrect parsing of device list to find ethener index of 
> plugged nic
> --
>
> Key: CLOUDSTACK-9491
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9491
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Murali Reddy
>Assignee: Murali Reddy
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> In VmwareResource.java, there is logic ( in findRouterEthDeviceIndex) to find 
> ethernet interface a mac address is associated with.
> After NIC in plugged in to a Vm through vSphere, it takes some time for the 
> device to show up in the guest VM.
> Logic loops through the device list obtained from /proc/sys/net/ipv4/conf 
> from the VM, and matched againest mac.
> However '/proc/sys/net/ipv4/conf'  is not refreshed, heve logic loops through 
> old device list always.
> In addition there is no exception thrown and error is maked by sending -1. 
> Eventually, VR scripts are getting -1 as device number causing failure in 
> processing the scripts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15523036#comment-15523036
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9489:


Github user pdion891 commented on the issue:

https://github.com/apache/cloudstack/pull/1684
  
@dagsonstebo, did you upgrade to 4.9 ?  So far, I had no authentication 
issue upgrading to 4.7.


> When upgrading, Config.java new configuration are not updated.
> --
>
> Key: CLOUDSTACK-9489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Blocker
>
> When Upgrading CloudStack, new configurations (Global Settings) defined in  
> {{server/src/com/cloud/configuration/Config.java}} are not populated.
> This file changed in 4.5 and 4.6 and those configurations are not applied 
> when upgrading to post 4.6.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15523008#comment-15523008
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8830:


Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1677
  
@jburwell  test_vm_snaphot only. Originally all 4 tests inside it would 
fail. With the fix one test still fails but it is unrelated to this issue and a 
conversation started in PR871. We would need either revert PR871 or open a new 
PR to resolve 4th test failure.

Test to create VM snapshots ... === TestName: test_01_create_vm_snapshots | 
Status : SUCCESS ===
Test to revert VM snapshots ... === TestName: test_02_revert_vm_snapshots | 
Status : SUCCESS ===
Test to delete vm snapshots ... === TestName: test_03_delete_vm_snapshots | 
Status : SUCCESS ===
=== TestName: test_01_test_vm_volume_snapshot | Status : EXCEPTION ===




> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
> 
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the 
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing:  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 

[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15522994#comment-15522994
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
#1692 has been opened that replaces #1683 to address the ping test issue on 
the 4.8, 4.9, and master branches rather just master for the original PR.  
Testing the PR now.


> Virtual Routers don't handle Multiple Public Interfaces
> ---
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
>Reporter: dsclose
>  Labels: firewall, nat, router
>
> There are a series of issues with the way Virtual Routers manage multiple 
> public interfaces. These are more pronounced on redundant virtual router 
> setups. I have not attempted to examine these issues in a VPC context. 
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on 
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue 
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will 
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT 
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate 
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and 
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how 
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The 
> master.py script is responsible for setting public interfaces to UP during a 
> keepalived transition. Currently the check_is_up method of the CsIP class 
> brings all interfaces UP on both RvR. A proposed fix for this has been 
> discussed on the mailing list. That fix will leave public interfaces DOWN on 
> RvR allowing the keepalived transition to control the state of public 
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix 
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. 
> Assuming public interfaces should be default be DOWN on an RvR we need to 
> accommodate the fact that, as interfaces are created, no keepalived 
> transition occurs. This means that assigning an IP from a new public subnet 
> will have no effect (as the interface will be down) until the network is 
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two 
> iptables rules in the FORWARD chain of the filter table created for eth2 that 
> allow forwarding between eth2 and eth0. Equivalent rules are not created for 
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, 
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New 
> connections from guests that are destined for public networks are processed 
> like so:
> 1. Traffic is matched against the following rule in the mangle table that 
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
> 2. There are no "ip rule" statements that match a connection marked 0x0, so 
> the kernel routes the connection via the default gateway. That gateway is on 
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, the following rule is matched from the nat table, where the IP 
> address is the source-NAT IP:
> *nat
> -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15522991#comment-15522991
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
@ustcweizhou thanks, i have fixed it earlier today and tested, am trying to 
fix other test failures and re-run the CI


> Virtual Routers don't handle Multiple Public Interfaces
> ---
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
>Reporter: dsclose
>  Labels: firewall, nat, router
>
> There are a series of issues with the way Virtual Routers manage multiple 
> public interfaces. These are more pronounced on redundant virtual router 
> setups. I have not attempted to examine these issues in a VPC context. 
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on 
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue 
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will 
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT 
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate 
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and 
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how 
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The 
> master.py script is responsible for setting public interfaces to UP during a 
> keepalived transition. Currently the check_is_up method of the CsIP class 
> brings all interfaces UP on both RvR. A proposed fix for this has been 
> discussed on the mailing list. That fix will leave public interfaces DOWN on 
> RvR allowing the keepalived transition to control the state of public 
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix 
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. 
> Assuming public interfaces should be default be DOWN on an RvR we need to 
> accommodate the fact that, as interfaces are created, no keepalived 
> transition occurs. This means that assigning an IP from a new public subnet 
> will have no effect (as the interface will be down) until the network is 
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two 
> iptables rules in the FORWARD chain of the filter table created for eth2 that 
> allow forwarding between eth2 and eth0. Equivalent rules are not created for 
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, 
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New 
> connections from guests that are destined for public networks are processed 
> like so:
> 1. Traffic is matched against the following rule in the mangle table that 
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
> 2. There are no "ip rule" statements that match a connection marked 0x0, so 
> the kernel routes the connection via the default gateway. That gateway is on 
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, the following rule is matched from the nat table, where the IP 
> address is the source-NAT IP:
> *nat
> -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15522979#comment-15522979
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
@murali-reddy FYI
```
diff --git a/systemvm/patches/debian/config/opt/cloud/bin/merge.py 
b/systemvm/patches/debian/config/opt/cloud/bin/merge.py
index c6ed190..7f3dbbc 100755
--- a/systemvm/patches/debian/config/opt/cloud/bin/merge.py
+++ b/systemvm/patches/debian/config/opt/cloud/bin/merge.py
@@ -217,6 +217,9 @@ class updateDataBag:
 elif (self.qFile.data['cmd_line']['type'] == "dhcpsrvr"):
 self.processCLItem('0', "guest")
 self.processCLItem('1', "control")
+elif (self.qFile.data['cmd_line']['type'] == "ilbvm"):
+self.processCLItem('0', "guest")
+self.processCLItem('1', "control")
 return cs_cmdline.merge(dbag, self.qFile.data)

 def processCLItem(self, num, nw_type):
```


> Virtual Routers don't handle Multiple Public Interfaces
> ---
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
>Reporter: dsclose
>  Labels: firewall, nat, router
>
> There are a series of issues with the way Virtual Routers manage multiple 
> public interfaces. These are more pronounced on redundant virtual router 
> setups. I have not attempted to examine these issues in a VPC context. 
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on 
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue 
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will 
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT 
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate 
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and 
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how 
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The 
> master.py script is responsible for setting public interfaces to UP during a 
> keepalived transition. Currently the check_is_up method of the CsIP class 
> brings all interfaces UP on both RvR. A proposed fix for this has been 
> discussed on the mailing list. That fix will leave public interfaces DOWN on 
> RvR allowing the keepalived transition to control the state of public 
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix 
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. 
> Assuming public interfaces should be default be DOWN on an RvR we need to 
> accommodate the fact that, as interfaces are created, no keepalived 
> transition occurs. This means that assigning an IP from a new public subnet 
> will have no effect (as the interface will be down) until the network is 
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two 
> iptables rules in the FORWARD chain of the filter table created for eth2 that 
> allow forwarding between eth2 and eth0. Equivalent rules are not created for 
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, 
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New 
> connections from guests that are destined for public networks are processed 
> like so:
> 1. Traffic is matched against the following rule in the mangle table that 
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
> 2. There are no "ip rule" statements that match a connection marked 0x0, so 
> the kernel routes the connection via the default gateway. That gateway is on 
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j 

[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15522976#comment-15522976
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8830:


Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1677
  
@serg38 I understand it is not an issue on ESXi 5.5.  From a regression 
test perspective, we need to run to regression tests to ensure this change does 
not introduce an issue with ESXi 5.5.  Which tests are you running to verify 
the change on ESXi 6?  I will run those on 5.5 to verify that no regressions 
have been introduced.


> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
> 
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the 
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing:  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878: 
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl] 
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local, 
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to 
> create snapshot for vm:i-84987-16119-VM due to null
> 2015-07-24 08:20:55,524 

[jira] [Commented] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15522970#comment-15522970
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9489:


Github user dagsonstebo commented on the issue:

https://github.com/apache/cloudstack/pull/1684
  
@abhinandanprateek @jburwell @pdion891 - my twopence worth - I've come 
across issues with this on two uprade projects in the last 8-10 months. Both 
cases were CCP to ACS upgrades:

1) In the first case we hit an issue where the admin account could log in - 
but no users. We carried out a preliminary check of this, and the suspicion was 
on changes in the MD5 authenticator - but the client eventually chose to just 
reset all users passwords, hence no accurate RCA carried out.

2) In the second, more recent case the client wanted to use either 
PLAINTEXT or MD5 authenticators, hence we updated the authenticators order 
similar to @pdion891 did above. During troubleshooting of this trace level 
logging showed the authenticator order in ACS4.9 was respected, no issues 
found. RCA of the underlying issue concluded with it being a user configuration 
and usage issue rather than a bug.


> When upgrading, Config.java new configuration are not updated.
> --
>
> Key: CLOUDSTACK-9489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Blocker
>
> When Upgrading CloudStack, new configurations (Global Settings) defined in  
> {{server/src/com/cloud/configuration/Config.java}} are not populated.
> This file changed in 4.5 and 4.6 and those configurations are not applied 
> when upgrading to post 4.6.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15522969#comment-15522969
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8830:


Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1677
  
@jburwell This issue doesn't manifest on ESX 5.5. We already confirmed it 
resolves the issue to up to 4.5 branch. test_vm_snapshot which fails on ESX 6 
now works fine. I can post test suite results shortly


> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
> 
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the 
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing:  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878: 
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl] 
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local, 
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to 
> create snapshot for vm:i-84987-16119-VM due to null
> 2015-07-24 08:20:55,524 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:8b87ab8a) Seq 80-6161487240196259878: 
> Response 

[jira] [Commented] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15522883#comment-15522883
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9489:


Github user pdion891 commented on the issue:

https://github.com/apache/cloudstack/pull/1684
  
@abhinandanprateek  I did replace the following 4 settings by the original 
values. But after restarting jetty I'm unable to login, but this time the 
behavior is a bit different, it look like it doesn't try to login, no log or 
message in the UI.

```
update configuration set value=null where 
name='user.password.encoders.exclude';
update configuration set value='SHA256SALT,MD5,LDAP,PLAINTEXT' where 
name='user.authenticators.order';
update configuration set value=null where 
name='user.authenticators.exclude';
update configuration set value='SHA256SALT,MD5,LDAP,PLAINTEXT' where 
name='user.password.encoders.order';
```

Could it be possible the  authentication order is not followed at the 
login? if the password does not meet ``PBKDF2`` requirement, which is the first 
in the order list of 4.9.0, shouldn't try with the next encoder in the list and 
so on?




> When upgrading, Config.java new configuration are not updated.
> --
>
> Key: CLOUDSTACK-9489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Blocker
>
> When Upgrading CloudStack, new configurations (Global Settings) defined in  
> {{server/src/com/cloud/configuration/Config.java}} are not populated.
> This file changed in 4.5 and 4.6 and those configurations are not applied 
> when upgrading to post 4.6.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15522631#comment-15522631
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
@jburwell i am investigating them. Just so you know, blueorangutan is 
running full smoke test suite. Similar failures are seen in other PR as well. 
So some of the tests may have been failing for some time and need to be fixed.

From the above list of failures test_router_dhcphosts are due to test 
errors that is being addressed by https://github.com/apache/cloudstack/pull/1683

I have addressed below two test failures. support for internal LB was not 
added in the logic creating ips.json databag, I made a fix for that as well.

test_02_internallb_roundrobin_1RVPC_3VM_HTTP_port80
test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80

rest of the failures i am investigating if they are regressions, and test 
failures.


> Virtual Routers don't handle Multiple Public Interfaces
> ---
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
>Reporter: dsclose
>  Labels: firewall, nat, router
>
> There are a series of issues with the way Virtual Routers manage multiple 
> public interfaces. These are more pronounced on redundant virtual router 
> setups. I have not attempted to examine these issues in a VPC context. 
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on 
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue 
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will 
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT 
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate 
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and 
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how 
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The 
> master.py script is responsible for setting public interfaces to UP during a 
> keepalived transition. Currently the check_is_up method of the CsIP class 
> brings all interfaces UP on both RvR. A proposed fix for this has been 
> discussed on the mailing list. That fix will leave public interfaces DOWN on 
> RvR allowing the keepalived transition to control the state of public 
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix 
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. 
> Assuming public interfaces should be default be DOWN on an RvR we need to 
> accommodate the fact that, as interfaces are created, no keepalived 
> transition occurs. This means that assigning an IP from a new public subnet 
> will have no effect (as the interface will be down) until the network is 
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two 
> iptables rules in the FORWARD chain of the filter table created for eth2 that 
> allow forwarding between eth2 and eth0. Equivalent rules are not created for 
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, 
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New 
> connections from guests that are destined for public networks are processed 
> like so:
> 1. Traffic is matched against the following rule in the mangle table that 
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
> 2. There are no "ip rule" statements that match a connection marked 0x0, so 
> the kernel routes the connection via the default gateway. That gateway is on 
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, 

[jira] [Commented] (CLOUDSTACK-9503) The router script times out resulting in failure of deployment

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15522456#comment-15522456
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9503:


Github user abhinandanprateek commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1678#discussion_r80427974
  
--- Diff: 
core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java ---
@@ -374,9 +375,9 @@ private Answer execute(AggregationControlCommand cmd) {
 FileConfigItem fileConfigItem = new 
FileConfigItem(VRScripts.CONFIG_CACHE_LOCATION, cfgFileName, sb.toString());
 ScriptConfigItem scriptConfigItem = new 
ScriptConfigItem(VRScripts.VR_CFG, "-c " + VRScripts.CONFIG_CACHE_LOCATION + 
cfgFileName);
 // 120s is the minimal timeout
-int timeout = answerCounts * _eachTimeout;
-if (timeout < 120) {
-timeout = 120;
+Duration timeout = 
_eachTimeout.withDurationAdded(_eachTimeout.getStandardSeconds(), answerCounts);
--- End diff --

@jburwell the java Duration that has multipliedBy is available from Java 8. 
Right now we are using joda.time.


> The router script times out resulting in failure of deployment
> --
>
> Key: CLOUDSTACK-9503
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9503
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0
> Environment: KVM, Xen
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.1.0
>
>
> When starting the virtual router in a shared network in advance zone the 
> scripts on router time out. This happen as there are several sub-commands 
> that are consolidated in a single command. The default timeout of 2 minutes 
> is short.
> 2016-09-09 00:06:25,016 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) process hasn't exited
> 2016-09-09 00:06:25,016 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) Command: com.cloud.agent.api.Command failed while starting 
> virtual router
> 2016-09-09 00:06:25,016 INFO [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) The guru did not like the answers so stopping 
> VM[DomainRouter|r-3445-VM]
> —



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9503) The router script times out resulting in failure of deployment

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15522453#comment-15522453
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9503:


Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/1678
  
@jburwell  ticket filed to refactor Script and SshHelper to use Duration. 
https://issues.apache.org/jira/browse/CLOUDSTACK-9508


> The router script times out resulting in failure of deployment
> --
>
> Key: CLOUDSTACK-9503
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9503
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0
> Environment: KVM, Xen
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.1.0
>
>
> When starting the virtual router in a shared network in advance zone the 
> scripts on router time out. This happen as there are several sub-commands 
> that are consolidated in a single command. The default timeout of 2 minutes 
> is short.
> 2016-09-09 00:06:25,016 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) process hasn't exited
> 2016-09-09 00:06:25,016 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) Command: com.cloud.agent.api.Command failed while starting 
> virtual router
> 2016-09-09 00:06:25,016 INFO [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) The guru did not like the answers so stopping 
> VM[DomainRouter|r-3445-VM]
> —



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9508) Change Script and SshHelper to use Duration instead of long timeout.

[Abhinandan Prateek (JIRA)]

Abhinandan Prateek created CLOUDSTACK-9508:
--

 Summary: Change Script and SshHelper to use Duration instead of 
long timeout.
 Key: CLOUDSTACK-9508
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9508
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.9.0
Reporter: Abhinandan Prateek
 Fix For: Future


Currently codebase uses long and int to represent various timeouts, this can 
create confusion as the unit of time is not carried with the value. With the 
use of Duration this confusion is removed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15522327#comment-15522327
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9489:


Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/1684
  
@jburwell yes we might have to further investigate this. I am waiting for 
info about the global params from @pdion891 to further this.
I think it will require a fix in upgrade scripts as the original 
authenticator should be preserved.


> When upgrading, Config.java new configuration are not updated.
> --
>
> Key: CLOUDSTACK-9489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Blocker
>
> When Upgrading CloudStack, new configurations (Global Settings) defined in  
> {{server/src/com/cloud/configuration/Config.java}} are not populated.
> This file changed in 4.5 and 4.6 and those configurations are not applied 
> when upgrading to post 4.6.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9319) Timeout is not passed to virtual router operations consistently

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15522306#comment-15522306
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9319:


Github user ozhanrk commented on the issue:

https://github.com/apache/cloudstack/pull/1451
  
Hi, last week we experience some problems because of the timeouts which 
mentioned on this PR. Could we get this PR to upcoming versions asap please. 
Without this timeout configuration functionality working, its very hard to make 
upgrades on VR, timeout issue generates real headaches.


> Timeout is not passed to virtual router operations consistently
> ---
>
> Key: CLOUDSTACK-9319
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9319
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
> Environment: KVM + Ceph cloud, Ubuntu hosts.
>Reporter: Aaron Brady
>Priority: Trivial
>
> The timeout parameter is not passed down to `applyConfigToVR` inside 
> `VirtualRoutingResource` in all cases.
> This timeout is worked out as 3 seconds per command or 120 seconds (whichever 
> is larger), but because it's not passed to the first invocation, the default 
> (120 seconds, DEFAULT_EXECUTEINVR_TIMEOUT) is used.
> In a recent upgrade of our Virtual Routers, the timeout was being hit and 
> increasing `router.aggregation.command.each.timeout` had no effect. I built a 
> custom 4.8 agent with the timeout increased to allow the upgrade to continue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)