Closed sboeuf closed 6 years ago
Playing with https://golang.org/pkg/plugin made me realize a few things we would need to allow hypervisor plugins on virtcontainers.
First we would need to export the entire hypervisor
interface:
type hypervisor interface {
init(pod *Pod) error
createPod(podConfig PodConfig) error
startPod() error
waitPod(timeout int) error
stopPod() error
pausePod() error
resumePod() error
addDevice(devInfo interface{}, devType deviceType) error
hotplugAddDevice(devInfo interface{}, devType deviceType) error
hotplugRemoveDevice(devInfo interface{}, devType deviceType) error
getPodConsole(podID string) string
capabilities() capabilities
}
to its exported version:
type hypervisor interface {
Init(pod *Pod) error
CreatePod(podConfig PodConfig) error
StartPod() error
WaitPod(timeout int) error
StopPod() error
PausePod() error
ResumePod() error
AddDevice(devInfo interface{}, devType deviceType) error
HotplugAddDevice(devInfo interface{}, devType deviceType) error
HotplugRemoveDevice(devInfo interface{}, devType deviceType) error
GetPodConsole(podID string) string
Capabilities() capabilities
}
Then, types deviceType
should be exported into DeviceType
.
The implementation of this API could only call into exported methods of objects passed as parameters here. Particularly, access to private fields of pod
in the Init(pod *Pod)
would be impossible and we should make sure to provide all the getters needed.
Looking into GetPodConsole(podID string)
also made me realize that we should make sure to provide/export everything that could be needed since we're using some non-exported const
paths.
Once all those requirements have been met, which is similar as considering the hypervisor as a separate package importing the virtcontainers
package, we can provide a new hypervisor interface implementation through hypervisor_plugin.go
with all the method of the interface (built into a hypervisor_plugin.so
).
Well now, as I write those lines, I am wondering if an indirection layer could be an easier way to handle this instead. Like having a dumb implementation of the hypervisor interface inside virtcontainers, something called plugin.go which would be a new hypervisor type implementing hypervisor
, and who would basically call into every function of the hypervisor_plugin.so
. As long as all plugins implement the same set of functions, this sort of shim layer would handle being an implementation of the hypervisor, because I am not sure we can define an implementation directly through a plugin.
And this would simplify things since we would not need to export the entire hypervisor
interface. Just need to make sure we create useful getters for already exported structures like Pod
.
cc @sameo
This issue was moved to kata-containers/runtime#146
We should investigate how we could allow proprietary hypervisor implementations as plugins into virtcontainers. One way would be to use https://golang.org/pkg/plugin/ in order to build such a plugin.