kata runtime library APIs about runtime

[sboeuf]

You're both right, we can have a library defining a high level API. I just want to make sure we try to define such a thing without relying on existing things like frakti so that we make this API convenient for an already exiting application. It would be more the other way around, which means we would define an API, and existing projects like frakti should adapt themselves to the newly defined API.

[sboeuf]

Well that's a good question ? Do we expect kata to provide such API ? If you look at CRI-O and CRI-containerd, they both rely on the runtime binary directly, assuming the runtime is compliant with OCI. Shouldn't frakti try to do the same ?
IMO, we are taking the problem upside down here.

[bergwolf]

@sboeuf Both virtcontainers and runv already have the library APIs. My proposal is to consolidate them to provide kata library APIs, which aligns with the goal of merging cc and runv. Given that we want to represent kata rather than either virtcontainers or runv to consumers, it makes sense to converge the libraries as well. Once we merge the libraries, we would have kata library APIs. And the issue is to define such APIs. It is next step now that we have both cc and runv cli in place.

And IMO we should not decide consumer architectures. The discussion among CRI-O/CRI-containerd/frakti is others' fight. As an OCI runtime implementation, it is better for kata to stand neutral.

[laijs]

@sboeuf IIRC, fratki is not a yet another CRI-tool, nor a yet another CRI-O/CRI-containerd.
It is the first implementation of the CRI which was originated born for fratki. It aims to leverage the best of vm containers to k8s. The aim will not be unchanged.

[WeiZhang555]

It would be fine to provide such a library as virtcontainers, I don't see any conflicts with our OCI-compatible goal, runc command line is also making using of libcontainer, so it would be OK to building a libkata(or better name), and kata-runtime command line can also be built based on this libkata. It's only about the detailed implementation of kata-runtime.

[bergwolf]

yes @sboeuf, frakti should be changed to use the new kata library API not the other way around.

[egernst]

I see this as addressed by https://github.com/kata-containers/documentation/blob/master/design/kata-api-design.md

Please re-open if I am mistaken.