[GitHub] cloudstack pull request: CLOUDSTACK-8915 - Cannot SSH into VMs dep...
Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/908#issuecomment-145230344 Hi @remibergsma @borisroman @DaanHoogland @miguelaferreira I executed the RVR test here, see results below: ``` Test redundant router internals ... === TestName: test_enableVPNOverRvR | Status : SUCCESS === ok -- Ran 1 test in 466.394s OK /tmp//MarvinLogs/test_redundant_router_services_3QFJ63/results.txt (END) ``` The test above does the following: 1 listNetworks should show the created network in allocated state 2 listRouters returns no running routers 3 VMs should be deployed and in Running state 4 should list 2 routers 5 listPublicIpAddresses for networkid should show acquired IP addr 6 listRemoteAccessVpns for the network associated should show VPN created 7 listRemoteAccessVpns for the network associated should return empty response I don;t consider it enough, so I will write a test that check the conntrackd service in the routers as well. Should the PR wait until the test is ready or if I do it manually now (to close this blocker quicker) would that be enough? Cheers, WIlder --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8868: use PasswordGenerator.ge...
Github user karuturi commented on the pull request: https://github.com/apache/cloudstack/pull/841#issuecomment-145255883 @wido we need another review. Also, since master is frozen, we cant push this at the moment. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8915 - Cannot SSH into VMs dep...
Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/908#issuecomment-145233418 Hi @remibergsma @borisroman @DaanHoogland @miguelaferreira @wido @runseb , I did the following manual tests: 1. Create a redundant network offering 2. Create a VM using the new net offering 3. Add egress rules to 0.0.0.0/0 - All 4. Acquired a new public IP 5. Created FW (0.0.0.0/0 - 22) and PF (22-22 towards the VM) ``` [root@cs1 integration]# ssh 192.168.23.5 The authenticity of host '192.168.23.5 (192.168.23.5)' can't be established. ECDSA key fingerprint is 69:80:c4:21:85:b1:fb:93:3c:75:86:8c:75:ae:3f:6b. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.23.5' (ECDSA) to the list of known hosts. root@192.168.23.5's password: # ls / bin dev homelib64 lost+found mnt procrun sys usr bootetc lib linuxrc media opt rootsbintmp var # ip route show default via 10.1.1.1 dev eth0 10.1.1.0/24 dev eth0 src 10.1.1.214 # ip addr 1: lo: mtu 65536 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 02:00:79:7f:00:03 brd ff:ff:ff:ff:ff:ff inet 10.1.1.214/24 brd 10.1.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::79ff:fe7f:3/64 scope link valid_lft forever preferred_lft forever # date Sat Oct 3 09:34:55 UTC 2015 # ``` I then tried the following as well: ``` # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes ^C --- 8.8.8.8 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss ``` As you can see, I could not ping google from inside the VM. I then went to the Master router and did: ``` root@r-14-VM:~# ip route show 10.1.1.0/24 dev eth0 proto kernel scope link src 10.1.1.213 169.254.0.0/16 dev eth1 proto kernel scope link src 169.254.0.7 192.168.23.0/24 dev eth2 proto kernel scope link src 192.168.23.4 ``` So, no default route on RVR routers. I then added them: ``` root@r-14-VM:~# route add default gw 192.168.23.1 root@r-14-VM:~# ip route show default via 192.168.23.1 dev eth2 10.1.1.0/24 dev eth0 proto kernel scope link src 10.1.1.213 169.254.0.0/16 dev eth1 proto kernel scope link src 169.254.0.7 192.168.23.0/24 dev eth2 proto kernel scope link src 192.168.23.4 root@r-14-VM:~# ``` After that, I went back to the VM and ping was successful! ``` # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=48 time=9.765 ms 64 bytes from 8.8.8.8: seq=1 ttl=48 time=9.801 ms 64 bytes from 8.8.8.8: seq=2 ttl=48 time=9.343 ms ^C --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 9.343/9.636/9.801 ms # ``` This bug is not related with this PR and was not mentioned before - probably nobody tested it. I would suggest to create a separate issue, which should include the fix and a test to cover it. What do you think? Concerning the conntrackd, I did the following: ``` root@r-14-VM:~# conntrackd -s ERROR: parsing config file in line (102), symbol 'Multicast': syntax error root@r-14-VM:~# ``` As you can see the configuration file is not good! And that's the same problem that was reported before. I also created a Redundant VPC in order to double check the conntrackd configuration in the routers. The results were as follows: ``` root@r-17-VM:~# root@r-17-VM:~# conntrackd -s cache internal: current active connections:1 connections created: 12failed:0 connections updated: 12failed:0 connections destroyed:11failed:0 cache external: current active connections:0 connections created: 4failed:0 connections updated: 0failed:0 connections destroyed: 4failed:0 traffic processed: 0 Bytes 0 Pckts multicast traffic (active device=eth2): 6820 Bytes sent 5864 Bytes
[GitHub] cloudstack pull request: CLOUDSTACK-8915 - Cannot SSH into VMs dep...
Github user remibergsma commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/908#discussion_r41087982
--- Diff: systemvm/patches/debian/config/opt/cloud/bin/cs/CsRedundant.py ---
@@ -96,7 +96,8 @@ def _redundant_on(self):
d = s.replace(".templ", "")
CsHelper.copy_if_needed(
"%s/%s" % (self.CS_TEMPLATES_DIR, s), "%s/%s" %
(self.CS_ROUTER_DIR, d))
-CsHelper.copy(
--- End diff --
OK, thanks!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] cloudstack pull request: CLOUDSTACK-8915 - Cannot SSH into VMs dep...
Github user wilderrodrigues commented on the pull request:
https://github.com/apache/cloudstack/pull/908#issuecomment-145237254
Guys,
There is also a glitch with the test_vpc_redundant.py: it was expected to
fail on the new test_routes, because the default route is broken on R-VPC -
which needs an issue first and a new PR.
The glitch on the test was:
```
self.assertEqual(
result.count("0% packet loss"),
1,
"Ping to outside world from VM should be
successful"
)
```
Which would pass if we get "100.0% packet loss"
I changed it for:
```
self.assertEqual(
result.count("3 packets received"),
1,
"Ping to outside world from VM should be
successful"
)
```
I will submit the changes on this PR later today or tomorrow morning.
Cheers,
Wilder
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] cloudstack-cloudmonkey pull request: Import error when running clo...
Github user syed commented on the pull request: https://github.com/apache/cloudstack-cloudmonkey/pull/10#issuecomment-145297866 This was a problem with my setup where I had multiple versions of `request`. Closing as not a bug --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack-cloudmonkey pull request: Import error when running clo...
Github user syed closed the pull request at: https://github.com/apache/cloudstack-cloudmonkey/pull/10 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
