add @mheon If you have worked on this or have any good idea, pls let me know.

I've been focusing on splitting sandbox (and a few related files) into a subpackage of server (or manager if this goes through). I'm trying to avoid having kpod create a daemon (as a debugging tool it doesn't really need one). The downside of this approach is that I need to untangle several large functions (notably RunPodSandbox in sandbox.go) to break them into parts both kpod and cri-o will share, and parts only the cri-o server will require.

@mheon

I'm trying to avoid having kpod create a daemon

Why would you think this approach would create a daemon, do you mean conmon?

The downside of this approach is that I need to untangle several large functions (notably RunPodSandbox in sandbox.go) to break them into parts both kpod and cri-o will share, and parts only the cri-o server will require.

I have launching pod/containers in mind when doing this, I think we could use this large functions directly by passing the same parameters as server did to launch a pod/container. ( I am working on a demo based on this patch, although haven't enough time to finish that. ) While here I assumed that we can use kpod to launch a totally same pod as server did, so we need fully config( without api config and some internal state perhaps) in server to achieve that. If that's not correct, I shall rethink all this.

@Crazykev I was concerned that we'd have to create a new server every time we started up kpod, but I suppose that's not a big concern - we can use the same config file as cri-o initially and pick up everything we need from there.

Looking more at server, I do have some concerns around using its methods directly. Most of them accept Kubernetes API data structures as arguments, which might not be easy to create from CLI arguments. I haven't fully looked into this approach fully yet, so it might be fine, though.

@mheon

I was concerned that we'd have to create a new server every time we started up kpod

No, we don't need to create a new server when started up kpod, kpod also use manager as well. But from some point of view, you could say that, because I move all the config and state to manager, only leave what server need to do(accept request, handle it to manager, reply the result as response), and let manager deal with all the detail stuff. Except for a real daemon server that we don't need to launch.

Most of them accept Kubernetes API data structures as arguments, which might not be easy to create from CLI arguments.

Yep, I use that on purpose, many of the request/result of our kpod command (like create/run/status, etc.) will have a lot of argument, instead of designing some struct to pass it to manager, resue those( I've avoid using reqest/response struct directly) in kubernetes could help a lot. This also based on the assumption that we want to create the same pod/container/image like ocid server do.

ping @mrunalp @runcom. Do you agree on this approach?

This approach sounds fine to me, however, I want to hear from @mheon (or @mrunalp) since he was also working on splitting the core out of the server.

@runcom I've got no further objections, though I'd still like an OK from @mrunalp before moving forward, given this will couple kpod and cri-o a lot more tightly than we were initially planning

Could we do this in such a way to eventually make this handling into a library. So we could have libkpod or something, and have ocid rely on libkpod?

@rhatdan That seems like the next logical step if we take this approach, once we know how much code needs to be shared and what is kpod specific or cri-o specific..

I think separating out into a separate package sounds good. Maybe we can call it pkg/libpod? We can start work on this now that #189 is merged.