Extend Kepler using plugins over gRPC #1499
Description
What would you like to be added?
Once #1470 lands, we'll have a good base to look at modelling the Device and Accelerator interface over gRPC.
This would be a bi-dir RPC mechanism that allows:
- Devices/Accelerator plugins to register with Kepler
- Kepler to call into those plugins to get information and/or scrape metrics
Why is this needed?
This has a number of benefits:
- Device and Accelerator plugins can be developed out-of-tree which would greatly reduce the amount of code in the core of Kepler
- Given that ☝️ require vendor-specific SDKs and libraries, the Go dependencies in core Kepler and the container image sizes would reduce dramatically (up to 2GB reduction in image size due to NVML dependencies)
- Simplified build process 🎉 less build-tags and mock/dummy drivers required
- Simplified deployment. Kepler core can be deployed and started. Kepler drivers can be deployed and started separately - the only requirement is that the plugins can access the Kepler gRPC service. In the case of the Kepler K8s operator, it could decide which drivers get deployed to which nodes based on information about the type of GPU/Accelerators present!