...
- Kernel function marketplace
- Scoping point:
- Love this direction
- Please don’t call them kernel functions
- They can run in NIC processors, UM daemons, etc.
- Don’t limit to kernel
- XDP can run in card not in the kernel
- Suggested Name: eBPF Program Repository
- Well, received
- Licensing requirements
- eBPF programs could be GPL, but don’t have to be.
- eBPF programs can be written that do not use GPL’d code
- Marketplace should require labeling programs that have restrictive licensing
- Kernel version
- Governance standards:
- Choice of licensing is dependent on publisher.
- eBPF programs written for the same purpose could be licensed differently
- As easy as the app store
- What is the level of trust in the marketplace?
- Who will review the programs and what standards should we have?
- Technical standards
- [ex] Program chaining
- legal standards
- Required snippets
- Multiple marketplaces
- Public/private, etc.
- How do you vet the code?
- Varies by what repo you are using
- Reputation system
- Fully automated
- Human intervention
- All are valid, but there should be some heterogeneity between them.
- Should they just be GitHub repos with automated builds?
- Make a website or some interface to access these?
- Reputation system sounds good.
- How do we couple the marketplace with L3AFd?
- Tightly or loosely coupled?
- Push down a config w/repo to pull from and them pull the prog
- Push down a config w/repo and the prog
- Should we support 1 or both of these
- Marketplace level, Orchestrater level, L3AFd level?
- Allow unsigned eBPF programs in the control plane?
- Do we flag them?
- The modules must be signed in the public marketplace
- They can do whatever they want in their own repo
- Tightly or loosely coupled?
- Scoping point:
Action Items
- Begin next week's meeting with: Proposals on L3af with Kubernetes