Hi Klement,
We’re patching mpls.py – in include nsh.py for reference.
This run worked:
-rw-r--r-- 1 nranns nranns 918 2017-01-05 08:15:39.151230150 -0500 mpls.py
-rw-r--r-- 1 nranns nranns 1499 2017-01-05 08:15:39.655234966 -0500 mpls.pyc
-rw-r--r-- 1 nranns nranns 2737 2017-01-05 08:15:38.631225000 -0500 nsh.py
-rw-r--r-- 1 nranns nranns 3745 2017-01-05 08:15:38.895227000 -0500 nsh.pyc
this run failed:
-rw-r--r-- 1 nranns nranns 918 2017-01-05 08:53:46.697139915 -0500 mpls.py
-rw-r--r-- 1 nranns nranns 1286 2017-01-05 08:53:46.325136000 -0500 mpls.pyc
-rw-r--r-- 1 nranns nranns 2737 2017-01-05 08:53:46.057133000 -0500 nsh.py
-rw-r--r-- 1 nranns nranns 3745 2017-01-05 08:53:46.325136000 -0500 nsh.pyc
Is the time-stamp accuracy only to the nearest second?
Thanks,
neale
On 05/01/2017, 13:04, "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at
Cisco)" <ksek...@cisco.com> wrote:
Neale,
the byte code should be always updated if out of date on import, if
it's not so, then that would be a python bug, which seems improbable.
If you are able to repro this, could you check the timestamps for the
correspoding .py/.pyc files? Maybe somehow the .py file's timestamp is
in the past (from .pyc POV)?
Thanks,
Klement
Quoting Neale Ranns (nranns) (2017-01-05 13:39:44)
> Hi Dave,
>
>
>
> After a little more experimentation I think this error is related to
the
> way we patch scapy post install. The scapy installation comes with byte
> code, after we apply the patch this byte code may or may not be
updated.
> If I force the generation of the byte code by either ‘touch
> <SCAPY>/mpls.py’ or ‘find <SCAPY> -name *.pyc –exec rm \;’ then all is
> well. The find and rm command I can add to the makefile. But there
must be
> a better way.
>
> Ideas? My python noob skills are stretched as it is J
>
>
>
> Thanks,
>
> neale
>
>
>
>
>
> From: Dave Wallace <dwallac...@gmail.com>
> Date: Wednesday, 4 January 2017 at 18:19
> To: "Neale Ranns (nranns)" <nra...@cisco.com>, "Klement Sekera -X
> (ksekera - PANTHEON TECHNOLOGIES at Cisco)" <ksek...@cisco.com>,
"Maciek
> Konstantynowicz (mkonstan)" <mkons...@cisco.com>
> Cc: "csit-...@lists.fd.io" <csit-...@lists.fd.io>,
"vpp-dev@lists.fd.io"
> <vpp-dev@lists.fd.io>
> Subject: Re: [csit-dev] [vpp-dev] vpp make test for verify - are we
> there yet ? [awoken]
>
>
>
> Neale,
>
> I could not find scapy installed in the normal path (i.e. "which
> scapy"), but I'm not sure if it is directly executable. You can find
> the "V=1 TEST=mpls make test" output on
> vagrant+virtualbox:puppetlabs/ubuntu-16.04.64-nocm in this pastebin
> doc: [1]http://pastebin.com/uGAUREhK
>
> Thanks,
> -daw-
>
> On 1/4/2017 10:59 AM, Neale Ranns (nranns) wrote:
>
>
>
> Hi,
>
>
>
> The reason the MPLS tests are failing is because scapy cannot
decode
> an MPLS label stack (output from some .show() instrumentation);
>
>
>
> <class 'scapy.layers.l2.Ether'>
>
> ###[ Ethernet ]###
>
> dst = 02:01:00:00:ff:02
>
> src = 02:fe:e5:05:0e:13
>
> type = 0x8847
>
> ###[ MPLS ]###
>
> label = 33L
>
> cos = 0L
>
> s = 0L <<<<<< NON End-of-stack
>
> ttl = 254
>
> ###[ Padding ]###
>
> load = '\x00\x061\xffE\x00\x00#\x00\x01\x00\x00@\x11
>
\xa6\xac\x10\x01\x01\xac\x10\x01\x02\x04\xd2\x04\xd2\x00\x0f\xd0\x92257
> 1 1'
>
>
>
> we patch scapy for this purpose, see;
>
> <ROOT>/test/patches/scapy-2.3.3/mpls.py.patch
>
>
>
> on my vagrant 14.04 there is no other scapy installation, this
patch
> applies fine and all MPLS tests pass.
>
> On a UCS 14.04, with another scapy installation:
>
> /usr/local/lib/python2.7/dist-packages/scapy/contrib/mpls.py
>
> the MPLS test fail.
>
> On a UCS 16.04 no scpay installation, tests pass.
>
>
>
> Do you have scapy installed in the machines on which the tests
> fail/pass? Or am I barking up the wrong virtualenv tree J
>
>
>
> Thanks,
>
> neale
>
>
>
>
>
>
>
> From: Dave Wallace [2]<dwallac...@gmail.com>
> Date: Wednesday, 4 January 2017 at 15:38
> To: "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at
Cisco)"
> [3]<ksek...@cisco.com>, "Maciek Konstantynowicz (mkonstan)"
> [4]<mkons...@cisco.com>, "Neale Ranns (nranns)"
> [5]<nra...@cisco.com>
> Cc: [6]"csit-...@lists.fd.io" [7]<csit-...@lists.fd.io>,
> [8]"vpp-dev@lists.fd.io" [9]<vpp-dev@lists.fd.io>
> Subject: Re: [csit-dev] [vpp-dev] vpp make test for verify - are
we
> there yet ? [awoken]
>
>
>
> Klement,
>
> I'm in the process of modifying the base Vagrantfile/build
scripts
> to replace building the VPP native package and installing it in
the
> VM to simply running "make test" which takes much less time.
All of
> the test runs that I have performed are clean builds on a virgin
git
> clone repo.
>
> That being said, I'll give the "git clean -dfX */" a try and see
if
> I get different results on the 2nd pass and report back.
>
> Thanks,
> -daw-
>
> On 1/4/17 10:23 AM, Klement Sekera -X (ksekera - PANTHEON
> TECHNOLOGIES at Cisco) wrote:
>
> Hi Dave,
>
>
>
> could you please try running git clean -dfX */ in a workspace, where you
see
>
> the failures, and then givet it another try? For me this seems to clear
issues
>
> up. Damjans recent changes might have caused (quoting Damjan) "major
>
> disturbances in the force", leaving build artifacts behind.
>
>
>
> Just be sure to stash/commit any changes you have in the workspace since
>
> the git clean nukes everything unknown from the ws.
>
>
>
> Thanks,
>
> Klement
>
>
>
> Quoting Dave Wallace (2017-01-04 16:12:38)
>
> As I mentioned on the VPP call yesterday, I'm seeing what appears to
be
>
> the same GRE test failures on Ubuntu 16.10 (bare metal). I'm also
seeing
>
> the same failures on vagrant+virtualbox with
>
> puppetlabs/ubuntu-16.04.64-nocm. I also am getting failures on 3 out
of 4
>
> MPLS tests on both environments.
>
>
>
> However, all tests pass on vagrant+virtualbox with
>
> puppetlabs/ubuntu-14.04.64-nocm.
>
>
>
> Thanks,
>
> -daw-
>
>
>
> On 1/4/17 9:47 AM, Maciek Konstantynowicz (mkonstan) wrote:
>
>
>
> baremetal trusty:
>
>
>
> $ lsb_release -a
>
> No LSB modules are available.
>
> Distributor ID: Ubuntu
>
> Description: Ubuntu 14.04.4 LTS
>
> Release: 14.04
>
> Codename: trusty
>
> $ uname -a
>
> Linux homes1 3.16.0-77-generic #99~14.04.1-Ubuntu SMP Tue Jun 28
19:17:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>
>
>
> -Maciek
>
>
>
>
>
> On 4 Jan 2017, at 13:42, Neale Ranns (nranns) [1][10]<nra...@cisco.com>
wrote:
>
>
>
>
>
> Hi Klement, Maciek,
>
>
>
> What environment are you running the tests in?
>
> I get different results. Running in the default vagrant env provided in
17.0. Everything passes apart from:
>
>
>
> ======================================================================
>
> Bidirectional Forwarding Detection (BFD)
>
> ======================================================================
>
> verify session goes down after inactivity OK
>
> hold BFD session up OK
>
> large remote RequiredMinRxInterval ERROR [
temp dir used by test case: /tmp/vpp-unittest-BFDTestCase-F7O6hZ ]
>
> bring BFD session up ERROR [
temp dir used by test case: /tmp/vpp-unittest-BFDTestCase-F7O6hZ ]
>
> verify slow periodic control frames while session down ERROR [
temp dir used by test case: /tmp/vpp-unittest-BFDTestCase-F7O6hZ ]
>
> no packets when zero BFD RemoteMinRxInterval ERROR [
temp dir used by test case: /tmp/vpp-unittest-BFDTestCase-F7O6hZ ]
>
>
>
> details below. Different runs give different combinations of failures
from this BFD list.
>
>
>
> /neale
>
>
>
> =====================================================================
>
> ERROR: large remote RequiredMinRxInterval
>
> ----------------------------------------------------------------------
>
> Traceback (most recent call last):
>
> File "/vpp/test/test_bfd.py", line 257, in test_large_required_min_rx
>
> self.bfd_session_up()
>
> File "/vpp/test/test_bfd.py", line 219, in bfd_session_up
>
> p = self.wait_for_bfd_packet()
>
> File "/vpp/test/test_bfd.py", line 171, in wait_for_bfd_packet
>
> p = self.pg0.wait_for_packet(timeout=timeout)
>
> File "/vpp/test/vpp_pg_interface.py", line 217, in wait_for_packet
>
> self.wait_for_capture_file(timeout)
>
> File "/vpp/test/vpp_pg_interface.py", line 204, in
wait_for_capture_file
>
> raise Exception("Capture file did not appear within timeout")
>
> Exception: Capture file did not appear within timeout
>
>
>
> ======================================================================
>
> ERROR: bring BFD session up
>
> ----------------------------------------------------------------------
>
> Traceback (most recent call last):
>
> File "/vpp/test/test_bfd.py", line 234, in test_session_up
>
> self.bfd_session_up()
>
> File "/vpp/test/test_bfd.py", line 219, in bfd_session_up
>
> p = self.wait_for_bfd_packet()
>
> File "/vpp/test/test_bfd.py", line 171, in wait_for_bfd_packet
>
> p = self.pg0.wait_for_packet(timeout=timeout)
>
> File "/vpp/test/vpp_pg_interface.py", line 217, in wait_for_packet
>
> self.wait_for_capture_file(timeout)
>
> File "/vpp/test/vpp_pg_interface.py", line 204, in
wait_for_capture_file
>
> raise Exception("Capture file did not appear within timeout")
>
> Exception: Capture file did not appear within timeout
>
>
>
> ======================================================================
>
> ERROR: verify slow periodic control frames while session down
>
> ----------------------------------------------------------------------
>
> Traceback (most recent call last):
>
> File "/vpp/test/test_bfd.py", line 187, in test_slow_timer
>
> self.wait_for_bfd_packet()
>
> File "/vpp/test/test_bfd.py", line 171, in wait_for_bfd_packet
>
> p = self.pg0.wait_for_packet(timeout=timeout)
>
> File "/vpp/test/vpp_pg_interface.py", line 217, in wait_for_packet
>
> self.wait_for_capture_file(timeout)
>
> File "/vpp/test/vpp_pg_interface.py", line 204, in
wait_for_capture_file
>
> raise Exception("Capture file did not appear within timeout")
>
> Exception: Capture file did not appear within timeout
>
>
>
> ======================================================================
>
> ERROR: no packets when zero BFD RemoteMinRxInterval
>
> ----------------------------------------------------------------------
>
> Traceback (most recent call last):
>
> File "/vpp/test/test_bfd.py", line 201, in test_zero_remote_min_rx
>
> p = self.wait_for_bfd_packet()
>
> File "/vpp/test/test_bfd.py", line 171, in wait_for_bfd_packet
>
> p = self.pg0.wait_for_packet(timeout=timeout)
>
> File "/vpp/test/vpp_pg_interface.py", line 217, in wait_for_packet
>
> self.wait_for_capture_file(timeout)
>
> File "/vpp/test/vpp_pg_interface.py", line 204, in
wait_for_capture_file
>
> raise Exception("Capture file did not appear within timeout")
>
> Exception: Capture file did not appear within timeout
>
>
>
> Ran 64 tests in 84.161s
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 04/01/2017, 09:45, [2][11]"csit-dev-boun...@lists.fd.io on behalf of
Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)"
[3][12]<csit-dev-boun...@lists.fd.io on behalf of ksek...@cisco.com> wrote:
>
>
>
> I tried doing a git checkout origin/stable/1701 - is that the correct
>
> branch? On that one, the GRE indeed doesn't work, but I don't think
it's
>
> 'make test' issue, here's a sample from packet trace:
>
>
>
> ------------------- Start of thread 0 vpp_main -------------------
>
> Packet 1
>
>
>
> 00:00:07:119382: pg-input
>
> stream pcap1, 88 bytes
>
> current data 0, length 88, free-list 6, trace 0x0
>
> IP4: 02:01:00:00:ff:02 -> 02:fe:39:17:74:65
>
> GRE: 2.2.2.2 -> 172.16.1.1
>
> tos 0x00, ttl 64, length 74, checksum 0xc96f
>
> fragment id 0x0001
>
> GRE 0x0001
>
> 00:00:07:119802: ethernet-input
>
> IP4: 02:01:00:00:ff:02 -> 02:fe:39:17:74:65
>
> 00:00:07:120048: ip4-input
>
> GRE: 2.2.2.2 -> 172.16.1.1
>
> tos 0x00, ttl 64, length 74, checksum 0xc96f
>
> fragment id 0x0001
>
> GRE 0x0001
>
> 00:00:07:120113: ip4-lookup
>
> fib 0 dpo-idx 5 flow hash: 0x00000000
>
> GRE: 2.2.2.2 -> 172.16.1.1
>
> tos 0x00, ttl 64, length 74, checksum 0xc96f
>
> fragment id 0x0001
>
> GRE 0x0001
>
> 00:00:07:120404: ip4-local
>
> GRE: 2.2.2.2 -> 172.16.1.1
>
> tos 0x00, ttl 64, length 74, checksum 0xc96f
>
> fragment id 0x0001
>
> GRE 0x0001
>
> 00:00:07:120495: gre-input
>
> GRE: tunnel 0 len 74 src 2.2.2.2 dst 172.16.1.1
>
> 00:00:07:120543: error-drop
>
> gre-input: unknown protocol
>
>
>
> all 50 packets printed in the packet trace share the same fate...
>
>
>
> Thanks,
>
> Klement
>
>
>
> Quoting Maciek Konstantynowicz (mkonstan) (2017-01-03 18:46:19)
>
>
>
> // Typed this email before the live discussion on vpp call just now -
>
> still sending it out :)
>
> Hello, After the previous ver of this thread went into a frenzy of
emails
>
> and fixes in vpp make test code,
>
> I wanted to re-check the situation.
>
> And as it is a New Year, I’m not lazy anymore, and did run make test
in
>
> both vpp branches :)
>
> vpp master branch works, stable/1701 does not..
>
> 1. master
>
> Ran 65 tests in 90.838s
>
> OK (skipped=5)
>
> make[1]: Leaving directory `/home/maciek/src/vpp2/test'
>
> 2. stable/1701
>
>
======================================================================
>
> ERROR: GRE tunnel Tests
>
> Exception: Capture file did not appear within timeout
>
>
======================================================================
>
> ERROR: GRE tunnel L2 Tests
>
> Exception: Capture file did not appear within timeout
>
>
======================================================================
>
> ERROR: MPLS Local Label Binding test
>
> AttributeError: label
>
>
======================================================================
>
> ERROR: MPLS label imposition test
>
> IndexError: Layer [IP] not found
>
>
======================================================================
>
> ERROR: MPLS label swap tests
>
> AttributeError: label
>
>
======================================================================
>
> ERROR: MPLS Tunnel Tests
>
>
----------------------------------------------------------------------
>
> IndexError: Layer [IP] not found
>
> Ran 64 tests in 59.980s
>
> FAILED (errors=6, skipped=5)
>
> make[1]: *** [test] Error 1
>
> make[1]: Leaving directory `/home/maciek/src/vpp2/test'
>
> make: *** [test] Error 2
>
> Fix?
>
> -Maciek
>
>
>
> On 12 Dec 2016, at 16:19, Maciek Konstantynowicz (mkonstan)
>
> [4][13]<[1]mkons...@cisco.com> wrote:
>
> Hello, Does anyone know if vpp make test is back on track to be
ready to
>
> be used for vpp make verify jobs on a per patch basis?
>
> Being lazy I know - cause I could run it myself :)
>
> -Maciek
>
>
>
> References
>
>
>
> Visible links
>
> 1. [5][14]mailto:mkons...@cisco.com
>
>
>
> _______________________________________________
>
> csit-dev mailing list
>
> [[15]6]csit-...@lists.fd.io
>
> [7][16]https://lists.fd.io/mailman/listinfo/csit-dev
>
>
>
>
>
> _______________________________________________
>
> csit-dev mailing list
>
> [[17]8]csit-...@lists.fd.io
>
> [9][18]https://lists.fd.io/mailman/listinfo/csit-dev
>
>
>
> References
>
>
>
> Visible links
>
> 1. [19]mailto:nra...@cisco.com
>
> 2.
[20]mailto:csit-dev-boun...@lists.fd.ioonbehalfofklementsekera-x(ksekera-pantheontechnologiesatcisco)
>
> 3. [21]mailto:csit-dev-boun...@lists.fd.ioonbehalfofksek...@cisco.com
>
> 4. mailto:[[22]1]mkons...@cisco.com
>
> 5. [23]mailto:mkons...@cisco.com
>
> 6. [24]mailto:csit-...@lists.fd.io
>
> 7. [25]https://lists.fd.io/mailman/listinfo/csit-dev
>
> 8. [26]mailto:csit-...@lists.fd.io
>
> 9. [27]https://lists.fd.io/mailman/listinfo/csit-dev
>
>
>
>
>
> References
>
> Visible links
> 1. http://pastebin.com/uGAUREhK
> 2. mailto:dwallac...@gmail.com
> 3. mailto:ksek...@cisco.com
> 4. mailto:mkons...@cisco.com
> 5. mailto:nra...@cisco.com
> 6. mailto:csit-...@lists.fd.io
> 7. mailto:csit-...@lists.fd.io
> 8. mailto:vpp-dev@lists.fd.io
> 9. mailto:vpp-dev@lists.fd.io
> 10. mailto:nra...@cisco.com
> 11.
mailto:csit-dev-boun...@lists.fd.ioonbehalfofklementsekera-x%28ksekera-pantheontechnologiesatcisco%29
> 12. mailto:csit-dev-boun...@lists.fd.ioonbehalfofksek...@cisco.com
> 13. mailto:[1]mkons...@cisco.com
> 14. mailto:mkons...@cisco.com
> 15. mailto:6]csit-...@lists.fd.io
> 16. https://lists.fd.io/mailman/listinfo/csit-dev
> 17. mailto:8]csit-...@lists.fd.io
> 18. https://lists.fd.io/mailman/listinfo/csit-dev
> 19. mailto:nra...@cisco.com
> 20.
mailto:csit-dev-boun...@lists.fd.ioonbehalfofklementsekera-x%28ksekera-pantheontechnologiesatcisco%29
> 21. mailto:csit-dev-boun...@lists.fd.ioonbehalfofksek...@cisco.com
> 22. mailto:1]mkons...@cisco.com
> 23. mailto:mkons...@cisco.com
> 24. mailto:csit-...@lists.fd.io
> 25. https://lists.fd.io/mailman/listinfo/csit-dev
> 26. mailto:csit-...@lists.fd.io
> 27. https://lists.fd.io/mailman/listinfo/csit-dev
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
