-
Notifications
You must be signed in to change notification settings - Fork 472
Modify CI tests to use bf-pktpy module, with no scapy, except for EBPF backend tests #5145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 28 commits
83fe9fa
f33526a
39aeab2
16b81ad
a9914fa
f00659a
08d3bc5
0e2adff
fc52efa
d7ab59f
917521b
7effb81
4663b50
639e63c
5aafcf8
2e17ebe
ab8c527
8b184e1
49b3f5f
0a79fb1
652d722
63c4d63
a519c93
40ade0c
53bcaa8
7695ada
c550eb3
17ce595
28a6c26
71dcbae
d039511
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -51,6 +51,7 @@ jobs: | |
| - name: Build (Ubuntu 20.04) | ||
| run: | | ||
| tools/ci-build.sh | ||
| sudo pip3 install scapy==2.5.0 | ||
|
||
|
|
||
| - name: Run PTF tests for eBPF backend (Ubuntu 20.04) | ||
| run: sudo -E ./test.sh | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a big fan of this approach, let's wait until bf_pktpy is default?
Also just noticed, but
packet_pktpyappears to be a redundant name.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding making bf_pktpy the default choice for the ptf package: ptf has been around for 10 years, it is used in SONiC testing, and I have no idea how many other places it might be used now. My guess is that changing the default now is going to cause others pain for years to come, and us in the form of issues.
Is there an approach that is not based on environment variables that you are a fan of, that you can think of?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we confirm that this is actually the case? If the behavior of PTF is equivalent with bf_pktpy then downstream repositories should not notice any issues. If not, there is a bug in bf_pktpy. In general, I'd assume these repositories probably pull in scapy separately, like P4C did. Or they pin their PTF version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we confirm whether this will cause other projects pain for years to come, and us in the form of issues? I mean, sure, we can just change the default and find out in the next 2-3 years :-). The thing about a long-public project is that often you do not even know who all of its users are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is the exact problem to me. We do not have paying customers and users are not providing feedback so we are dealing with an effectively imaginary user base. I rather move on and make changes that are beneficial for the organization and keep complexity low instead of locking us down. We do not have the resources to be backwards compatible.
I also think it is common (good) practice to pin your dependencies, if a project always uses the latest version of software we provide, that's on them. We can change the major version of PTF to signal that it is a breaking change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. Let us imagine for a moment that we do change the default packet manipulation module in the ptf package to bf_pktpy.
In a recent commit today, I tried out running the EBPF tests using ptf with bf_pktpy as the packet manipulation module. It fails, raising exceptions from bf_pktpy about attributes and/or methods that the tests are trying to use not being present.
I am personally not interested in tracking these down and attempting to update bf_pktpy, not even to see how much work it might be. If we want EBPF backend tests to keep working without potentially significant time spent changing them, the most straightforward way is to use scapy as ptf's packet manipulation module for those tests. The way the tests are run right now, that can be done with extra command line options to the
ptfcommand.I am guessing that there will be other ptf users that will similarly want to continue using Scapy as its packet manipulation module, because of such issues.
Are you OK with recommending to those other people that they use the environment variable
PTF_PACKET_MANIPULATION_MODULE="ptf.packet_scapy"to continue using Scapy as their packet manipulation module, if they want to do so?If not, then I am currently at a loss for how to proceed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, seems reasonable to me. Like other Python projects we can print a big deprecation warning for a couple months that we are going to switch and then eventually switch with a major PTF release. This gives users enough of a headsup. Does that work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. And we can look into what it takes to cut a minor release with the current code soon-ish, just before making the backwards-compatible change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue on ptf repo to track this planned change of default: p4lang/ptf#222