bpfman: An eBPF Manager bpfman operates as an eBPF manager, focusing on simplifying the deployment and administration of eBPF programs. Its notable features encompass:
We do aim to have this included in Fedora so it becomes the de-facto and easy way to load eBPF programs.
Owners, do not implement this work until the FESCo vote has explicitly ended. The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.
REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the devel list thread linked above.
I hope the change owners are working to ensure this works on Fedora RISC-V too...
+1
Thanks neal, we'll sure aim to get this to every possible architecture. We're so far coordinating with Fabio Valentini on the builds (and on the needed rust dependencies to be added)
Procedural -1.
This is seems to be a nice tool, making some uses of bpf much easier.
Nevertheless, if I understand the Change Page and the discussion correctly, the title and the Summary are very misleading.
Bpfman as default eBPF manager it becomes the de-facto and easy way to load eBPF programs.
Bpfman as default eBPF manager
it becomes the de-facto and easy way to load eBPF programs.
but
For now we’ll just go ahead, package bpfman as you suggest and not install it as default.
I was trying to understand what the planned scope really is, and this discussion happened independently, so clearly I'm not the only one confused by this.
There are other uses of BPF. In particular, systemd has support for bpf internally, and it is extensively used to implement unit sandboxes (per-unit firewalls, device access limitations) and also allows loading arbitrary user programs via BPFProgram=. Thus, even if bpfman is installed by default, I don't think it'd be true to say that its the "de-facto way to load BPF programs".
BPFProgram=
I think we should wait with the approval until the title and Summary are clarified. (Scope actually only mentions packaging, but not every reader gets that far down in the page.)
Also, gRPC is a bit surprising. For communication between services, D-Bus would be a more natural choice. Maybe this is all OK, but I'd like to see more discussion before we start using a new protocol in the base layer of the system.
Hi Zbginew,
Thanks for asking for clarification over here.
I'm totally fine about changing the Summary to something along the lines of "Adding bpfman to Fedora 40" in this case.
Basically, out first goal is for this to be available in Fedora 40 despite any other tooling. Hope this clarifies things now.
Even if we aim for this to become a default tool for managing bpf programs in Fedora and to become a tool for every user to be able to load bpf programs in an easier way we can leave that out of the scope of this change.
Regarding gRPC and d-bus, that's something we may implement later but for now I hope that this section here https://bpfman.io/main/getting-started/example-bpf/#notes makes things clearer.
Thanks!
Hi FESCo members,
Is this change proposal going to be discussed in the next meeting? Or is @dmellado 's clarification above suitable to continue the vote?
Thanks! Aoife
Unless @zbyszek changes his vote, this remains targeted at the next meeting.
Metadata Update from @sgallagh: - Issue tagged with: meeting
That'd be great. Please make the change in the wiki.
Metadata Update from @zbyszek: - Issue untagged with: meeting
Hi @zbyszek . Thanks for the clarification over there and for having a chat with me at the FOSDEM conference. I've just updated the wiki page with the changes we spoke about and mention here, so I do hope that you're now ok with the change. Thanks!
Thank you.
It's exactly two weeks since the start of the voting, so let's mark this as: APPROVED (+6, 0, 0)
Metadata Update from @zbyszek: - Issue tagged with: pending announcement
Metadata Update from @sgallagh: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
I think it would be clearer to also rename the wiki page itself?
Indeed. Renamed to match the title: https://fedoraproject.org/wiki/Changes/Add_bpfman_to_Fedora
Metadata Update from @zbyszek: - Issue untagged with: pending announcement
Log in to comment on this ticket.