Posted from iPhone. Forgive top posting, and terse writing style..
--Thomas F Herbert SDN Group Office of Technology Red Hat > On Sep 25, 2017, at 1:03 PM, Klement Sekera -X (ksekera - PANTHEON > TECHNOLOGIES at Cisco) <ksek...@cisco.com> wrote: > > Quoting Thomas F Herbert (2017-09-25 13:31:55) >> On 09/25/2017 05:02 AM, Marco Varlese wrote: >> >> Thanks for the thorough explanation Klement!Based on that, I think (2) is >> still the better option for the current situation... >> >> Tom, how would that sound to you? >> >> >> "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" >> [1]<ksek...@cisco.com> 09/25/17 10:40 AM >>> >> >> Quoting Marco Varlese (2017-09-25 10:26:50) >> >> Hi Klement, >> >> >> "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" >> [2]<ksek...@cisco.com> 09/25/17 9:33 AM >>> >> >> At the time of creating this patch, epel was part of Makefile and >> python34 was installed as dependency from that repo. >> (see [3]https://gerrit.fd.io/r/#/c/6983/53/Makefile) >> At later time, the epel stuff disappeared and with it also >> the possibility to add python34 as a centos dependency - commit >> bd8e242024fcc2daffa77bdd6e2da1296ace5c69. I remember pointing this out >> in discussion with Neale, but I didn't get a chance to test whether >> centos works or not before it was merged. >> >> That's OK. You would have had to test with a system without EPEL Repo >> enabled to discover this problem. >> >> I should have paid closer attention when this patch was first discussed in >> May. Please add me as a reviewer for patches that have implications for >> RPM packaging and requirements. >> >> >> I think it would be nice though to update other scripts too so to have one >> single python version used across the board. >> Currently, to build VPP on our distribution I need to require both python >> and python3 packages since some python scripts use one rather than the other. >> Aligning python versions would make downstream consumption better I believe. >> Is this something which will/could be done? >> >> See below. >> >> >> >> As for the solution, I can think of 3 options: >> >> 1.) require python3 (which has been around for some ~9 years now) >> 2.) disable generation of the C (and C++) API if python3 is not detected >> >> I think this would be a fair compromise for distros not supporting (yet) >> python3. However, I am not sure how this would result in the VPP CI... >> wouldn't this break all tests running over those API? >> >> Tests are python2.7 because scapy wasn't python3 capable when we >> designed the test framework. >> >> These are language bindings, not different API calls. Only test_vapi, >> which tests that the language bindings of different types (simple >> request, dump, event, etc.) work would have to be disabled. >> >> I think this is a good interim work-around until the distros have Python3. >> I can submit another patch to allow this the inclusion would be enabled as >> a default but could be disabled only in downstream builds in RHEL and >> Centos 7. >> >> When will we have tests in CSIT that use the C/C++ APIs in 17.10? >> >> Neale, are we planning to cherry-pick this patch into 17.10? >> >> Do we have yet tests in CSIT that use the C/C++ APIs in 17.10? > > Let me rephrase my words to clarify possible confusion which I see. New > C/C++ API bindings are just a way of calling old VPP APIs in a more > user-friendly way. They still call e.g. sw_interface_dump - there is no > change to APIs themselves. > > So it's important to distinguish between API (e.g. sw_interface_dump) > and API binding (which is a language-specific way of constructing > sw_interface_dump message and sending it over shared memory to VPP). > > I don't know about CSIT, but "make test" tests use python API bindings, > which internally uses old C API bindings (vapiclient). Unless we want > to remove old C API, there is little motivation to rework python API > binding as it contains more or less the same logic as the new C/C++ API > bindings. > > There is one test though which doesn't - test_vapi.py, which builds its > own test client binary for both new C and new C++ API to make sure that > it builds, links and executes as intended. It doesn't call python API > bindings at all, it only sets up the infra for running a test and then > spawns a binary, which does the actual testing (vs running native python > code as is the case for most of the other tests). > > Now to answer your questions: > > 1.) there is no CSIT test which uses new C/C++ API > 2.) there is only one "make test" test which uses new C/C++ API > (test_vapi), which is part of this change. > > To disable this partially on centos, we need to exclude > > a.) vpp-api/vapi/Makefile.am (don't build) > b.) test/ext/Makefile (don't build) > c.) test/test_vapi.py (don't run) - we can add code to skip this easily > if we can detect centos e.g. via some kind of environment variable from > within python.. OK, I volunteer to work on a disabling patch. Thanks. > >> >> >> >> 3.) convert the script to python2.7 (which is in the opposite direction of >> where we would want to go wrt python version) >> >> Thanks, >> Klement >> >> Cheers, >> Marco >> >> Quoting Thomas F Herbert (2017-09-23 15:55:10) >> >> All: >> >> Commit 8f2a4ea, Gerrit, [1][4]https://gerrit.fd.io/r/#/c/6983/ "Add new C >> API" >> >> introduces a dependency on Python 3 and breaks downstream builds for >> Centos. >> >> Unfortunately, neither RHEL nor Centos currently support Python 3. >> >> Most VPPers are probably building with EPEL repo so this problem didn't >> show up until now but actually there is no dependency on EPEL in the >> Makefile or spec file. >> >> If anybody can suggest a solution short of pushing Python 3 into the >> downstream repos, I am open to suggestions. >> >> --Tom >> >> -- >> Thomas F Herbert >> NFV and Fast Data Planes >> Office of Technology >> Red Hat >> >> References >> >> Visible links >> 1. [5]https://gerrit.fd.io/r/#/c/6983/ >> >> _______________________________________________ >> vpp-dev mailing list >> [6]vpp-dev@lists.fd.io >> [7]https://lists.fd.io/mailman/listinfo/vpp-dev >> >> >> >> >> -- >> Thomas F Herbert >> NFV and Fast Data Planes >> Office of Technology >> Red Hat >> >> References >> >> Visible links >> 1. mailto:ksek...@cisco.com >> 2. mailto:ksek...@cisco.com >> 3. https://gerrit.fd.io/r/#/c/6983/53/Makefile >> 4. https://gerrit.fd.io/r/#/c/6983/ >> 5. https://gerrit.fd.io/r/#/c/6983/ >> 6. mailto:vpp-dev@lists.fd.io >> 7. https://lists.fd.io/mailman/listinfo/vpp-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
