Oh shoot, I never really learned the process.. Looking at the other email, I've already screwed this up on multiple levels as I did not file a JIRA and committed to master instead of release throttle. How do we proceed in these cases?
Quoting Billy McFall (2017-10-05 17:08:50) > Klement, > Thank you for the path "drop python3 dependency" on master > ([1]https://gerrit.fd.io/r/#/c/8584/), it will make ours lives downstream > much easier. I don't see the patch on stable/1710. Is there a plan to > cherry pick to 1710? (Sorry if it already there, just didn't see it.) > Thanks, > Billy McFall > On Mon, Sep 25, 2017 at 8:03 AM, Klement Sekera -X (ksekera - PANTHEON > TECHNOLOGIES at Cisco) <[2]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]<[3]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]<[4]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][5]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][6]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][7]https://gerrit.fd.io/r/#/c/6983/ > > > > _______________________________________________ > > vpp-dev mailing list > > [6][8]vpp-dev@lists.fd.io > > [7][9]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:[10]ksek...@cisco.com > > 2. mailto:[11]ksek...@cisco.com > > 3. [12]https://gerrit.fd.io/r/#/c/6983/53/Makefile > > 4. [13]https://gerrit.fd.io/r/#/c/6983/ > > 5. [14]https://gerrit.fd.io/r/#/c/6983/ > > 6. mailto:[15]vpp-dev@lists.fd.io > > 7. [16]https://lists.fd.io/mailman/listinfo/vpp-dev > _______________________________________________ > vpp-dev mailing list > [17]vpp-dev@lists.fd.io > [18]https://lists.fd.io/mailman/listinfo/vpp-dev > > -- > Billy McFall > SDN Group > Office of Technology > Red Hat > > References > > Visible links > 1. https://gerrit.fd.io/r/#/c/8584/ > 2. mailto:ksek...@cisco.com > 3. mailto:ksek...@cisco.com > 4. mailto:ksek...@cisco.com > 5. https://gerrit.fd.io/r/#/c/6983/53/Makefile > 6. https://gerrit.fd.io/r/#/c/6983/ > 7. https://gerrit.fd.io/r/#/c/6983/ > 8. mailto:vpp-dev@lists.fd.io > 9. https://lists.fd.io/mailman/listinfo/vpp-dev > 10. mailto:ksek...@cisco.com > 11. mailto:ksek...@cisco.com > 12. https://gerrit.fd.io/r/#/c/6983/53/Makefile > 13. https://gerrit.fd.io/r/#/c/6983/ > 14. https://gerrit.fd.io/r/#/c/6983/ > 15. mailto:vpp-dev@lists.fd.io > 16. https://lists.fd.io/mailman/listinfo/vpp-dev > 17. mailto:vpp-dev@lists.fd.io > 18. 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
