containers / virtcontainers

A Go package for building hardware virtualized container runtimes
Apache License 2.0
139 stars 43 forks source link

Add an hypervisor implementation as a plugin #667

Closed sboeuf closed 6 years ago

sboeuf commented 6 years ago

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.

sboeuf commented 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.

sboeuf commented 6 years ago

cc @sameo

egernst commented 6 years ago

This issue was moved to kata-containers/runtime#146