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.. > > > > 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
