Hi Klement, It’s okay :-)
Just open a ticket, cherry-pick the patch and append the jira ticket id to the subject. That should be enough. Cheers, Florin > On Oct 5, 2017, at 8:11 AM, Klement Sekera -X (ksekera - PANTHEON > TECHNOLOGIES at Cisco) <ksek...@cisco.com> wrote: > > 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 _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
