Fixed issues with test_vpc_vpn script

[sanju1010]

There are few issues with this test file. Please refer to JIRA Ticket https://issues.apache.org/jira/browse/CLOUDSTACK-9102 for details on the issues that have been fixed.

[sanju1010]

Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn | Status : SUCCESS ===
ok

---

Ran 1 test in 169.692s

OK
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : FAILED ===
FAIL

FAIL: Test VPN in VPC

Traceback (most recent call last):
File "D:\CCPRepo\internal-cloudstack\test\integration\smoke\test_vpc_vpn.py", line 695, in test_vpc_site2site_vpn
self.assert_(int(packet_loss) == 0, "Ping did not succeed")
AssertionError: Ping did not succeed
-------------------- >> begin captured stdout << ---------------------
=== TestName: test_vpc_site2site_vpn | Status : FAILED ===

The second test failure is not related to these changes. It is something to do with the connectivity issues between the vms.

[remibergsma]

@sanju1010 Thanks for the PR. Can you make it PEP8 compliant again please?

Most tests seem to create the offering the test needs. Isn't that a better idea?

I will run your version of the test. The previous one always succeeds for me, but I agree with the hypervisor specific part. That should be generic.

Will run it and report back.

[michaelandersen]

Just tested this on 4.6.1-SNAPSHOT with the command:

nosetests --with-marvin --marvin-config=/data/shared/marvin/mct-zone1-xen1.cfg -a tags=advanced,required_hardware=true /tmp/test_vpc_vpn.py

and it failed:

Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn | Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : EXCEPTION ===
ERROR

======================================================================
ERROR: Test VPN in VPC
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/test_vpc_vpn.py", line 712, in test_vpc_site2site_vpn
    self.assert_(int(packet_loss) == 0, "Ping did not succeed")
ValueError: invalid literal for int() with base 10: 'received,'
-------------------- >> begin captured stdout << ---------------------
=== TestName: test_vpc_site2site_vpn | Status : EXCEPTION ===


--------------------- >> end captured stdout << ----------------------

I'm pretty sure this has to do with: https://github.com/sanju1010/cloudstack/blob/09409a7ac264e864c45146927b86229c8e67fbc8/test/integration/smoke/test_vpc_vpn.py/#L711

field 7 was changed to field 6 of the ping output

[michaelandersen]

ping @sanju1010

[remibergsma]

Doesn't work for me either:

Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn | Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : EXCEPTION ===
ERROR

The original one works:

Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn | Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS ===
ok

----------------------------------------------------------------------
Ran 2 tests in 1054.998s

OK

[sanju1010]

Hi Remi,

As I mentioned in my PR the second test failure is related to connectivity
issues between the vms part of s2s vpn. It is not because of my changes.

Thanks,
Sanjeev
On Dec 7, 2015 7:48 PM, "Remi Bergsma" notifications@github.com wrote:

Doesn't work for me either:

Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn | Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : EXCEPTION ===
ERROR

The original one works:

Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn | Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS ===
ok

---

Ran 2 tests in 1054.998s

OK

—
Reply to this email directly or view it on GitHub
#1156 (comment).

[eriweb]

@sanju1010 the error lies in the script due to different outputs. the test seems to use macchinina as template, which has the following output for ping:

ping -c 1 -t 1 x.y.z.40

PING x.y.z.40 (x.y.z.40): 56 data bytes

--- x.y.z.40 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

The cut on line 711 picks field 6, which is 'received' and not 0.

a regular debian derivate has the following output:
--- x.y.z.40 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

where your cut would match '+1' and work.

conclusion; either change the template or change the cut

[remibergsma]

👎 Tests are failing, we need to fix it before we consider a merge, sorry.

[michaelandersen]

So removed my last comment about field 7 to 6. We need to choose 1 type of template os for both kvm and xen and base the test on that. @sanju1010: the machininna was already in there and working for kvm at least. would you mind making that template work?

[asfbot]

Sanjeev N on dev@cloudstack.apache.org replies:
@michaelandersen, if we want to use that template it only works for kvm. So
either we have to skip the tests for other hypervisors or make the similar
templates for all other hypervisors as well.

[eriweb]

@sanju1010 it works for XenServer as well atleast, haven't tried VMware. But you'll have to change your script to adjust to the different output

[asfbot]

Sanjeev N on dev@cloudstack.apache.org replies:
@terbolour, as per the previous logic in the test, it will register
xenserver template for any hypervisor other than kvm and vm deployment
fails for other hypervisors like vmware,hyper-v and lxc.
So I was asking how we should handle this.

[michaelandersen]

Gotcha. We could add templates for the other hypervisors (vmware and hyperv) from http://dl.openvm.eu/cloudstack/macchinina/x86_64/

And remove the default_hypervisor variable and replace it for a dynamic template selection based on the nosetests hypervisor parameter.

[asfbot]

Sanjeev N on dev@cloudstack.apache.org replies:
Thanks @michaelandersen, I will take those templates and make the test
generic.

[wilderrodrigues]

@sanju1010

Are you still working on this? It's currently holding us a bit because we need to do some work on this test as well. For instance, I want to make it rVPC compliant.

The point is: I'm trying to avoid conflicts when merging your changes with my changes.

If that would be fine, I would like to suggest I take it over. I already applied some fixes to the test_internal_lb.py, which was suffering from the same problem. See PR #1204

Is that okay if I take it over?

Cheers,
Wilder

[asfbot]

Sanjeev N on dev@cloudstack.apache.org replies:
@wilder, I am ok with it. You can take it over.
One comment, is ostype "Other PV (64-bit)" valid for other hypervisors
otherthan Xenserver? And vmware template format should be in .ova
The one you have mentioned in the Services class won't work.

[asfbot]

Sanjeev N on sanjeev@apache.org replies:
@wilder, forgot to mention, either we should also add template for LXC or
skip the test for LXC.

[michaelandersen]

Hi @sanju1010, @wilderrodrigues asked me to extend the test_vpc_vpn script and in the proces i added the other hypervisors.
#1276
Could you review?

[swill]

Is this PR still relevant or did the changes in the other mentioned PRs make this PR outdated? If it is still active, please rebase the PR to get rid of merge conflicts so we can more easily test and merge this code. Thx...

[sanju1010]

@swill, PR #1276 outdated this PR. So closing this.